분산 시스템의 세션 처리

서버 독립 세션

아래 그림과 같습니다.
서버 독립적 세션에서는 각 사용자 요청이 동일한 응용 프로그램 서버에서 작동되어야 하며, 이를 위해서는 로드 밸런싱 서버가 사용자 요청을 매번 동일한 주소의 서버로 보내야 합니다.
첫 번째 사용자가 처음 접속하는 1번 서버는 로드 밸런싱 서버에 의해 사용자 세션 내내 1번 서버로 지정되어야 합니다. 다른 서버에서는 1번 사용자의 세션 정보를 저장하지 않습니다.

요즘 로드밸런싱 서버에는 일반적으로 이 기능(nginx)이 있습니다

그러나 다음과 같은 상황이 발생하면

이때 서버 1이 다운되면 로드 밸런싱 서버는 사용자 1을 서버 2 또는 3으로 리디렉션하지만 사용자는 서버 2와 3에 안전한 컨텍스트가 없으며 서버는 사용자에게 다시 로그인하도록 알립니다. 이 사용자 경험은 분명히 영향을 받을 것입니다. 그리고 사용자 데이터 손실이 발생할 가능성이 매우 높습니다.

각 서버가 모든 세션을 유지합니다

각 서버가 모든 사용자 세션을 유지합니다. 이는 애플리케이션 서버 간의 세션 동기화 문제와 관련이 있으며 실시간 요구 사항이 상대적으로 높습니다. 이 방법을 사용하면 다음 그림과 같이 위 서버의 독립 세션에서 발생하는 문제를 피할 수 있습니다.

장점

이 방법은 첫 번째 방법이 발생합니다. 이 경우 1번의 세션 정보는 2번과 3번 서버에도 저장됩니다. 로드 밸런싱 서버에 장애가 발생하여 1번 사용자를 2번과 3번 서버로 리디렉션하면, 서버는 사용자 번호 1의 보안 컨텍스트도 찾습니다. 다시 로그인할 필요 없이 계속 액세스할 수 있습니다.

단점

그러나 이 방법에도 단점이 있습니다. 즉, 애플리케이션 서버의 세션 동기화에 대한 실시간 요구 사항이 상대적으로 높고 추가적인 크로스 밴드 오버헤드가 발생한다는 것입니다. 세션이 멀리 있을 때 상황이 바뀌면 동기화가 필요합니다. 세션의 정보량이 상대적으로 크면 상당한 메모리를 소비하게 됩니다.

서버 공유 세션

서버 공유 세션 정보 :

장점

각 사용자의 세션 정보가 저장됩니다. 애플리케이션 외부의 다른 서버(데이터베이스 또는 KV 스토리지 서비스일 수 있음)에 저장하므로 애플리케이션 서버는 각 사용자의 세션 정보를 저장할 필요가 없으므로 많은 메모리 오버헤드가 절약됩니다.

서로 다른 애플리케이션 서버가 세션 정보를 사용해야 할 경우 공유 세션 서버로 이동하여 정보를 얻습니다.

이렇게 하면 로드 밸런싱 서버가 사용자를 고정 서버에 할당할 필요가 없고, 서버 간 세션 정보를 복사할 필요도 없습니다. 세션 정보가 변경되면 애플리케이션 서버가 해당 서버로 이동하게 됩니다. 공유 서버를 수정하려면 정보가 충분합니다.

단점

공유 서버에 더 의존하거나 공유 서버 클러스터에 문제가 발생하면 사용자에게 큰 영향을 미칩니다.

쿠키로 세션 데이터를 전송합니다.

쿠키에 사용자 정보를 저장하면 불안정한 요인을 제거할 수 있지만, 쿠키에는 여전히 보안상의 위험성이 숨어 있고, 쿠키에도 길이 제한이 있습니다.

').addClass('사전 번호 매기기').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i ').text(i)); }; $numbering.fadeIn(1700); }); });

위 내용은 분산 시스템에서의 세션 처리에 대한 내용을 포함하여 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.