¿Puede la replicación de la sesión tiene lugar sin una sesión pegajosa?

Question

En el contexto de Tomcat, ¿puede la replicación de la sesión que tiene lugar sin habilitar la sesión Sticky?

Entiendo que el propósito de Sticky Session es tener al cliente 'Sticks' a 1 servidor durante toda la sesión. Con la replicación de la sesión, la interacción del cliente con el servidor se replica en todo el clúster (muchos servidores web).

En el caso anterior, ¿puede tener lugar la replicación de la sesión? La sesión del cliente de IE se extiende a través de los servidores web y cada interacción con cualquier servidor web se replica, por lo tanto, lo que permite una interacción perfecta.

Answer 1

Afaik, Tomcat Clustering no admite sesiones no pegajosas. De Tomcat Docs:

Asegúrese de que su LoadBalancer esté configurado para el modo de sesión pegajosa.

Pero hay una solución (creé, así que sabes que estoy parcial :-)) llamado gerente de sesión memcached (MSM), que también admite sesiones no pegajosas. MSM usa memcached (o cualquier backend que hable el protocolo Memcached) como backend para la copia de seguridad/almacenamiento de la sesión.

En las sesiones de modo no pegajosas solo se almacenan en Memcached y ya no en Tomcat, como con las sesiones no estancadas, la tienda de sesión debe ser externa (para evitar datos obsoletos).

También es compatible con el bloqueo de la sesión: con sesiones no sencillas, las solicitudes paralelas pueden golpear diferentes Tomcats y podrían modificar la sesión en paralelo, para que algunos de los cambios de sesión puedan ser sobrescritos por otros. El bloqueo de la sesión permite la sincronización de solicitudes paralelas que van a diferentes Tomcats.

los Página de inicio de MSM describe principalmente el enfoque de la sesión pegajosa (como comenzó solo con esto), para obtener detalles sobre las sesiones no estancadas que puede buscar o preguntar en el lista de correo.

Los detalles y ejemplos con respecto a la configuración se pueden encontrar en el MSM Wiki (configuración setupandconfiguración).

Solo para darle una idea sobre la complejidad: lo que necesita es uno o más memcached Servidores que se ejecutan (o S.TH. Similar Memcached) y un contexto Tomcat actualizado.xml como este:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

Su Balancer de carga no necesita una configuración especial, por lo que una vez que tenga estas cosas en su lugar, puede comenzar a probar su aplicación.

Answer 2

Un excelente artículo sobre este tema aquí:

• http://www.mulesoft.com/tomcat-cluster

El producto de terracota que mencionan tiene un tutorial simplista aquí:

• http://www.terracotta.org/documentation/websessions/get-started

La terracota funciona en Tomcat, pero debe prestar atención para verificar qué fragmentos de terracota son gratuitos y cuáles son comerciales. Hace un par de años, se pagó su tienda redundante y no recuerdo que esta solución fuera un producto separado.

Answer 3

De hecho, he encontrado lo inverso a esta pregunta. La replicación de sesión para mí (TomCat7) con las opciones OOTB solo funciona correctamente sin una sesión pegajosa. Después de encender el registro, descubrí que con los JVMroutes habilitados, mi ID de sesión va de A123456789 a A123456789.01 - sufijo con el JVMroute. Esa sesión se replica correctamente desde el nodo 01 en el clúster al nodo 02 pero usa la misma ID (A123456789.01). Cuando saco el nodo 01 del clúster, el tráfico comienza a quedarse en el nodo 02, y ahora se ve para una sesión A123456789.02 que, por supuesto, no existe. .01 está allí, pero básicamente queda inactivo hasta que expire. Si levanto el otro servidor y las sesiones se replican y luego tomo 02 hacia abajo, obtengo un comportamiento aún más desagradable porque la sesión se retira donde lo dejó.

Para mí, hasta ahora, la replicación de sesión sin sesiones adhesivas (solo RR regular entre los nodos en el clúster) es lo único que ha funcionado.