톰캣 인스턴스 간의 세션 공유 (끈끈한 세션 사용 안 함)

Question

3 개의 Tomcat 서버와 'sticky sessions'을 사용하지 않고 요청을 보내는 Load Balancer를 갖습니다.

서버간에 세션 데이터를 공유하려고합니다. DB에서 세션 데이터를 유지하려고합니다. 내 서버 앞에있는 레이어로 memcached을 사용하여 더 빨리 요청을 처리하고 don't put my db under heavy load으로 보내고 싶습니다.

나는 그것을하기 위해 투명한 방법을 보지 못하는 순간에 세션 데이터를 DB에 저장/유지하기 전에 memcached를 사용하는 사용자 정의 된 Tomcat Manager를 제공 할 생각입니다. 다시 다른 앱 서버로 전환하는 경우).

이 방법이 좋은 해결책입니까 아니면 더 나은 방법이 있습니까?

Answer 1

Google 애플리케이션 (Weblogic, 그러나 상관 없습니다)에서 비슷한 세션 키가 브라우저에 쿠키로 저장되어 있습니다. 이 키는 각 요청시 데이터베이스에서 관련 세션 데이터를 복원하는 데 사용됩니다.

이 원칙을 사용하면로드 밸런서를 사용하여 다른 서버로 전환 할 수 있습니다. 그 외에도 사용자 세션과 관련된 항목은 저장하지 않고 브라우저의 많은 숨겨진 필드와 함께 작업합니다 (로드 밸런서는 URL 암호화 및 양식 값 보호를 지원하므로 안전한쪽에 있습니다 ...) .

Answer 2

나는 Terracotta Web Sessions을 원한다고 생각합니다.

Answer 3

응용 프로그램 서버 (귀하의 경우 Tomcat) 외부에 세션 상태를 저장하는 것은 대규모 웹 사이트에 매우 일반적이며 권장되는 구성입니다. 이것은 일반적으로 Shared Nothing이라는 아키텍처 스타일을 추구하여 수행됩니다.

db, memcached, 상업용 복제 된 캐시 등 여러 다른 장소에 상태를 저장할 수 있습니다. 이들은 모두 서로 다른 트레이드 오프의 조합으로 작동합니다. 개인적으로 memcached를 통해 큰 성공을 거두었습니다. Memcached는 매우 빠르고 안정적입니다.

일반적으로 N Memcache 서버를 N> 1, 2로 사용합니다. 사용자가 로그인 할 때 앱 서버는 동전을 뒤집어 사용자가 저장하는 서버 저장소를 결정합니다. 브라우저로 전송 된 쿠키에는 이후에 라우팅 할 Memcache 서버를 알 수있는 정보가 들어 있습니다. 브라우저의 후속 요청은 각 요청에 대해 적절한 memcache 서버에서 상태를 가져옵니다. memcache 서버가 실패하면 사용자는 새로운 서버를 다시 선택하기 때문에 다시 로그인해야하지만 매우 드뭅니다.

Answer 4

데이터베이스의 세션을 지속하면 확장 성이 제한됩니다. 확장 성이 그다지 중요하지 않은 경우 (db + memcached) 유효한 접근 방식입니다.

비 정적 세션을 사용할 때 염두에 두어야 할 사항 중 하나는 동시 요청입니다. (동시에/동시에 실행되는) Ajax 요청 (서로 끈적 거리지 않음으로 인해)이 서로 다른 톰캣에 의해 서비스되고 따라서 동시에 세션에 액세스합니다. 세션을 수정할 수있는 동시 요청이있는 한 일종의 동기화/세션 잠금을 구현해야합니다.

아마도 이것은 당신에게 중요합니다. 최적의 성능과 무제한의 확장 성을 목표로 memcached-session-manager을 만들었습니다. memcached 호환 백엔드 (예 : memcachedb, membase 등 또는 memcached)와 함께 작동 할 수 있습니다. 원래는 끈적 세션 방식을 위해 제작되었지만 이미 branch for nonsticky-sessions이 있고 how/that 작동을 보여주는 sample app이 있습니다. 지금은 thread on the mailing list on further improvements for nonsticky-sessions (동시 요청 처리 및 단일 지점 오류 방지)이 있습니다.