클러스터형 WEB 애플리케이션은 다소 세션 문제에 직면하게 됩니다. 여러 서버의 경우 세션의 키 저장으로 인해 몇 가지 문제가 발생하고 사용자 경험에 영향을 미칠 수 있습니다.

다음은 제가 생각할 수 있는 여러 처리 방법의 목록이며 각각 장점과 단점이 있습니다

• 클라이언트가 고정 서버에 바인딩되도록 ip_hash과 같은 Nginx 로드 정책을 구성하여 최종 사용자가 액세스하는 시스템이 고정되도록 session이 로컬에 저장되도록 합니다. 사용자 사용에는 영향을 미치지 않습니다. 하지만 두 가지 주요 단점이 있습니다.

1. ip_hash배포가 고르지 않고, 특히 ip_hash에 사용된 Nginx가 프론트 엔드가 아닌 경우 이 전략을 사용할 수 없습니다

2. 로드 밸런스 문제를 고려하지 않으면 여전히 존재하는 문제는 백엔드 머신이 다운되면 <에 기록된 사용자 데이터가 이 머신의 모든 session을 잃게 된다는 것입니다. 🎜> 인증 상태인 경우 사용자는 미인증 상태가 됩니다session

• 서버(Nginx 프록시 서버) 간에

  브로드캐스트를 수행합니다. 이 방법의 문제점은 클러스터 규모가 확장되면 브로드캐스트 성능이 매우 저하된다는 점입니다. 일반적으로 session 사용을 권장하지 않습니다. 🎜 >

• 에서는

  나 session의 구체적인 사용법을 다루지 않습니다. redis를 사용하는 방법도 매우 간단합니다. 🎜> 저장소 구현을 위해 교체하여 사용할 수도 있습니다. memcached의 redis 또는 session 구현을 동적으로 수정하려면 redis 메서드를 사용하세요. 중앙 집중식 저장소가 (로컬 저장소와 비교하여) 성능에 특정 영향을 미친다는 점을 제외하면 나머지는 거의 완벽합니다. 구현 코드는 충분히 강력합니다 HttpServletRequestWrapper session memcached-session-managerspring-session저도 잘못된 방법을 생각해 냈는데 그것은 단지 아이디어일 뿐이고 한번도 사용한 적이 없습니다.

  클러스터 규모가 확장되면 브로드캐스트 방식의 성능이 저하되므로 모든 머신 간에 브로드캐스트하는 대신 두 머신 또는 세 머신 간에 브로드캐스팅을 수행할 수 있습니다. 두 머신이 그룹이라고 가정하면 클러스터에 있는 모든 서버는 두 대의 기계로 방송됩니다. 방송국은 단위로 그룹화되어 서로 방송됩니다
이때 서로 방송하는 두 기계가 동시에 끊기지 않는지 확인하면 됩니다(^_^ 보장은 없는 것 같아요!)

• session session위의 방법 외에도 다른 방법도 있을 텐데요, 관심 있으신 분들은 오셔서 토론해 보세요

부록

[2016/9/1]

을 기반으로 하는 분산형 애플리케이션에는 한계가 많다고 생각합니다.

,
등과 같은 타사 저장소에 직접 저장할 수 있으며 이는 session 공유 솔루션이지만 상대적으로 더 급진적입니다. servlet