Compartir sesiones entre instancias de tomcat (sin utilizar Sesiones adhesivas)

Question

Voy a tener 3 servidores Tomcat y un Load Balancer que distribuye las solicitudes sin usar 'sticky sessions'.

Quiero compartir los datos de las sesiones entre los servidores y estoy pensando en mantenerlos en DB. Me gustaría utilizar memcached como una capa en frente de mi base de datos para atender las solicitudes más rápido y al don't put my db under heavy load.

Estoy pensando en proporcionar mi Administrador personalizado de tomcat que use memcached antes de obtener/persistir datos de sesión en DB ya que en este momento no veo una forma transparente de hacerlo (significa que tendré que gestionarlo) de nuevo en el caso de que cambie a otro servidor de aplicaciones).

¿Es esta una buena solución o ve un mejor enfoque?

Answer 1

Hacemos algo similar en nuestra aplicación (Weblogic, pero eso no importa), donde tenemos una clave de sesión única almacenada como una cookie en el navegador. Esa clave se usará en cada solicitud para restaurar los datos de sesión relevantes de la base de datos.

Usando este principio, siempre podemos cambiar a otro servidor usando el equilibrador de carga sin que el usuario note nada. Además de eso, apenas almacenamos nada relevante en la sesión del usuario y trabajamos con muchos campos ocultos en el navegador (el equilibrador de carga admite cifrado de URL y protección de valor de formulario, por lo que estamos seguros). .

Answer 2

Creo que Terracotta Web Sessions es lo que quieres.

Answer 3

Almacenar su estado de sesión fuera de los servidores de aplicaciones (Tomcat en su caso), es una configuración muy común y recomendada para sitios web a gran escala. Esto se hace generalmente en busca de un estilo de arquitectura llamado Shared Nothing.

Puede almacenar su estado en varios lugares diferentes: db, memcached, caché comercial replicada, etc. Todos ellos funcionan con diferentes mezclas de compensaciones. Personalmente, he tenido un gran éxito con memcached. Memcached es extremadamente rápido y estable.

En general, opto por la simplicidad y uso N servidores de Memcache donde N> 1, por ejemplo 2. A medida que los usuarios inician sesión, los servidores de aplicaciones lanzan una moneda para decidir qué servidores almacenan los usuarios. La cookie enviada al navegador incluye información para saber a qué servidor de Memcache enrutar a partir de ese momento. Las solicitudes posteriores del navegador obtienen el estado del servidor Memcache apropiado en cada solicitud. En caso de que un servidor de Memcache falle, el usuario tendrá que volver a iniciar sesión cuando los servidores de la aplicación vuelvan a seleccionar un nuevo servidor, pero eso es extremadamente raro.

Answer 4

Las sesiones persistentes en la base de datos limitan su escalabilidad. Si la escalabilidad no es tan importante para usted, esto (db + memcached) es un enfoque válido.

Una cosa que debes tener en cuenta cuando usas sesiones no conflictivas son las solicitudes simultáneas: cuando tienes, por ejemplo, ajax-requests (ejecutados en paralelo/concurrentemente) serán servidos por diferentes tomcats (debido a la falta de adherencia) y, por lo tanto, acceden a la sesión al mismo tiempo. Siempre que tenga solicitudes simultáneas que puedan modificar la sesión, deberá implementar algún tipo de sincronización/bloqueo de sesión.

Quizás esto le interese: Creé el memcached-session-manager con el objetivo de lograr un rendimiento óptimo y una escalabilidad ilimitada. Puede funcionar con cualquier backend compatible con memcached (por ejemplo, también memcachedb, membase, etc. o simplemente memcached). Aunque originalmente se creó para un enfoque de sesiones adhesivas, ya existe un branch for nonsticky-sessions existente y un sample app que muestra cómo/eso funciona. Ahora mismo hay un thread on the mailing list on further improvements for nonsticky-sessions (manejo de solicitudes simultáneas y prevención del punto único de falla).