nginx가 로드 밸런싱을 수행할 때 동일한 IP의 URL이 서버를 요청하면 로드 밸런싱은 각 서버의 가중치 및 기타 설정에 따라 처리를 위해 요청을 다른 서버로 전달합니다. 이러한 방식으로 상태가 있는 일부 요청은 이런 경우에는 세션을 공유할 수 없는데 어떻게 해결해야 할까요?
session이 mysql
데이터베이스에 저장되어 있습니다. 세션 테이블 및 기타 데이터 테이블은 함께 저장되므로 사용자가 로그인하여 작업을 수행할 때 세션 상태를 확인하기 위해 데이터베이스로 이동해야 합니다. 이는 의심할 여지 없이 MySQL 데이터베이스에 대한 부담을 증가시킵니다. 데이터베이스도 클러스터링된 경우 각 데이터베이스 클러스터의 모든 노드는 이 세션 테이블을 저장해야 하며 각 클러스터 노드에 있는 데이터베이스의 세션 테이블에 있는 데이터가 실시간으로 일관되고 동기화되는지 확인해야 합니다. 세션이 데이터베이스에서 유지되므로 데이터베이스의 IO가 증가하고 데이터베이스의 크기가 증가합니다. 압력과 부담은 데이터베이스의 읽기 및 쓰기 성능에 영향을 미치며 mysql 클러스터는 실시간에 도움이 되지 않습니다. 세션 동기화는 Memcache 또는 Redis 캐시에 존재하며 저장 방법은 PHP 구성 파일에 설정됩니다. Memcache의 경우 PHP 자체가 세션 클러스터를 설정하고 Memcache에 세션 데이터를 저장합니다.
설명: 이 세션 동기화 방법은 데이터베이스에 대한 부담을 증가시키지 않으며 쿠키를 사용하여 세션을 저장하는 것에 비해 보안이 크게 향상됩니다. 세션을 메모리에 넣는 것이 파일에서 읽는 것보다 훨씬 빠릅니다. 그러나 Memcache는 메모리를 다양한 사양의 저장 블록으로 나누고 각 블록은 자체 크기를 갖습니다. 또한 이 방법은 Memcache가 메모리를 완전히 활용하지 못하고 저장 블록이 충분하지 않으면 메모리 오버플로가 발생한다고 판단합니다. .
ip_hash 기술
nginx는 특정 IP의 클라이언트가 특정 IP를 요청할 때 구성할 수 있습니다. IP 요청이 모두 지정된 서버에 할당될 때마다 Stateful 요청의 상태 무결성이 보장되고 상태 손실이 발생하지 않도록 다음은 nginx의 구성을 참조할 수 있습니다. to it:
upstream nginx.example.com { server 192.168.1.2:80; server 192.168.1.3:80; ip_hash; } server { listen 80; location / { proxy_pass http://nginx.example.com; } }
참고: ip_hash 솔루션은 실제로 상태와 함께 요청의 무결성을 보장할 수 있지만 큰 결함이 있습니다. 즉, ip_hash 솔루션은 Nginx가 프런트 엔드 서버인지 확인해야 합니다(실제 IP 허용) ), nginx가 프런트엔드 서버가 아닌 경우 미들웨어(중간 서버 등)도 있고 nginx에서 얻은 IP 주소는 실제 IP 주소가 아니며 이 ip_hash는 의미가 없습니다
Nginx 관련 추가 정보 기술 기사를 보려면 Nginx 사용법 튜토리얼 칼럼을 방문하여 공부하세요!
위 내용은 nginx가 세션을 공유하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!