nginx 로드 밸런서가 세션 공유를 처리하는 여러 가지 방법

1) 세션을 사용하는 대신 쿠키를 사용하세요

세션을 쿠키로 변경하면 세션의 단점을 일부 피할 수 있다는 점을 이전에 읽은 J2EE 책에서도 지적하고 있습니다. 클러스터 시스템 세션을 사용할 수 없습니다. 그렇지 않으면 문제가 발생하고 처리가 어려워집니다. 시스템이 복잡하지 않은 경우에는 세션을 제거할 수 있는지 여부를 우선으로 하여 변경이 매우 번거로운 경우에는 다음 방법을 사용하십시오.

2) 애플리케이션 서버는 자체적으로 공유를 구현합니다.

알려진 바와 같이 PHP는 데이터베이스나 memcached를 사용하여 세션을 저장함으로써 PHP 자체에 세션 클러스터를 구축할 수 있습니다. 세션이 가능합니다. 노드에 장애가 발생하더라도 세션이 손실되지 않습니다. 보다 엄격한 상황에 적합하지만 요청량이 적습니다. 그러나 효율이 그다지 높지 않아 고효율이 필요한 경우에는 적합하지 않습니다.

위의 두 가지 방법은 nginx와 관련이 없습니다. nginx를 사용하는 방법에 대해 이야기해 보겠습니다.

3) ip_hash

nginx의 ip_hash 기술은 특정 IP를 변환할 수 있습니다. 요청은 동일한 백엔드로 전달되므로 이 IP 아래의 클라이언트와 백엔드는 안정적인 세션을 설정할 수 있습니다. ip_hash는 업스트림 구성에 정의되어 있습니다.

upstream backend {
server 127.0.0.1:8001 ;
server 127.0.0.1:8002;
ip_hash;
}

ip_hash는 이해하기 쉽지만 백엔드 할당 요소는 ip만 사용할 수 있으므로 ip_hash에 결함이 있어 사용할 수 없습니다. 경우에 따라 사용됩니다.

1/ nginx는 프런트엔드 서버가 아닙니다. ip_hash를 사용하려면 nginx가 프런트엔드 서버여야 합니다. 그렇지 않으면 nginx가 올바른 IP를 얻을 수 없고 IP를 기반으로 해시할 수 없습니다. 예를 들어 Squid를 프런트 엔드로 사용하는 경우 nginx는 IP를 가져올 때 Squid의 서버 IP 주소만 가져올 수 있습니다. 이 주소를 배포에 사용하는 것은 확실히 혼란스럽습니다.

2/ nginx의 백엔드에는 다른 로드 밸런싱 방법도 있습니다. nginx 백엔드에 다른 로드 밸런싱이 있고 요청이 다른 방식으로 전환되는 경우 특정 클라이언트의 요청은 동일한 세션 애플리케이션 서버에 위치하지 않습니다. 이를 계산하면 nginx 백엔드는 애플리케이션 서버를 직접 가리키거나 Squid를 빌드한 다음 애플리케이션 서버를 가리킬 수만 있습니다. 가장 좋은 방법은 위치를 전환으로 사용하고, 세션이 필요한 일부 요청을 ip_hash를 통해 전환하고, 나머지는 다른 백엔드로 이동하는 것입니다.

4) upstream_hash

ip_hash의 일부 문제를 해결하기 위해 타사 모듈 upstream_hash를 사용할 수 있습니다. 이 모듈은 대부분의 경우 url_hash에 사용되지만 이를 방지하지는 않습니다. 세션 공유에 사용되지 않도록:

프런트 엔드가 Squid인 경우 x_forwarded_for http_header에 IP를 추가합니다. upstream_hash를 사용하여 이 헤더를 지정된 백엔드로 요청하는 요소로 사용합니다.

이 문서를 볼 수 있습니다:

http://www.oschina.net/discuss/thread/622

문서에서는 $request_uri가 인수로 사용됩니다. 변경됨:

hash $http_x_forwarded_for;

이런 방식으로 x_forwarded_for 헤더가 요소로 사용됩니다. nginx의 새 버전에서는 쿠키 값 읽기를 지원할 수 있습니다. 다음으로 변경:

hash $cookie_jsessionid;

php에 구성된 세션이 쿠키가 없는 경우 nginx의 자체 userid_module 모듈을 사용하면 nginx를 사용하여 쿠키를 생성할 수 있습니다