1) 세션을 사용하는 대신 쿠키를 사용하세요
세션을 쿠키로 변경하면 세션의 단점을 일부 피할 수 있습니다. 전에 J2EE 책에서 읽었습니다. , 또한 클러스터 시스템에서 세션을 사용할 수 없음을 나타냅니다. 그렇지 않으면 문제가 발생하고 처리가 어려워집니다. 시스템이 복잡하지 않은 경우에는 세션을 제거할 수 있는지 여부를 우선으로 하여 변경이 매우 번거로운 경우에는 다음 방법을 사용하십시오.
2) 애플리케이션 서버가 자체적으로 공유를 구현합니다.
알다시피 PHP는 데이터베이스나 memcached를 사용하여 세션을 저장하고 이를 통해 세션을 설정할 수 있습니다. PHP 클러스터 자체에서는 이러한 방식으로 세션의 안정성을 보장할 수 있습니다. 노드에 장애가 발생하더라도 세션이 손실되지는 않지만 요청량이 적은 경우에 적합합니다. 그러나 효율이 그다지 높지 않아 고효율이 필요한 경우에는 적합하지 않습니다.
위의 두 가지 방법은 nginx와 관련이 없습니다. nginx 사용 방법에 대해 이야기해 보겠습니다.
3) ip_hash
nginx의 ip_hash 기술은 특정 IP의 요청을 동일한 백엔드로 보낼 수 있으므로 이 IP 아래의 특정 클라이언트와 특정 백엔드는 ip_hash가 업스트림 구성에 정의되어 있습니다.
업스트림 백엔드 {
서버 127.0.0.1:8001;
서버 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를 사용할 수 있습니다. 그러나 대부분의 경우 세션 공유에 사용되는 것을 막지는 않습니다.
프런트 엔드가 오징어인 경우 x_forwarded_for http_header에 IP를 추가하고 upstream_hash를 사용하여 사용합니다. 이 헤더는 요청을 지정된 백엔드로 직접 전달하는 요소입니다.
이 문서 참조:
http://www.oschina.net/ 토론/스레드/622
문서에서 $request_uri가 요소로 사용되며 약간 변경되었습니다.
hash $http_x_forwarded_for;
이렇게 하면 x_forwarded_for 헤더를 요소로 사용하도록 변경되었습니다. 새 버전의 nginx에서는 쿠키 값 읽기를 지원할 수 있으므로 다음과 같이 변경할 수도 있습니다.
hash $cookie_jsessionid;
PHP에 구성된 세션이 쿠키가 없는 경우 nginx는 nginx 자체 userid_module 모듈을 사용하여 쿠키를 생성할 수 있습니다. 영어 설명서를 참조하세요. 사용자 ID 모듈:
http://wiki.nginx.org/NginxHttpUserIdModule
위 내용은 콘텐츠 측면을 포함하여 nginx 로드 밸런서가 세션 공유를 처리하는 여러 가지 방법을 소개합니다. 이 내용이 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.