Sesiones pegajosas y replicación de sesión

Question

Estoy evaluando el caso del uso de sesiones adhesivas con replicación de sesión en Tomcat. A partir de mi evaluación inicial, pensé que si habilitamos la replicación de la sesión, la sesión iniciada en un nodo Tomcat se copiará en todos los demás nodos Tomcat y, por lo tanto, no necesitamos una sesión pegajosa para continuar las sesiones y la solicitud puede ser recogida por cualquier nodo. .

Pero parece que la replicación de la sesión se usa en general con sesiones adhesivas, de lo contrario, la identificación de la sesión debe cambiarse cada vez que la solicitud va a algún otro nodo. árbitro: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#bind_session_after_crash_to_failover_node

¿Alguien puede explicar cuál es el uso real de la replicación de la sesión si tiene que habilitar la sesión de Sticky? Porque entonces estaría copiando innecesariamente la sesión en cada nodo, cuando la solicitud con una ID de sesión determinada siempre va al mismo nodo. Podría ser beneficioso en caso de que un nodo se bloquee, pero eso no sucede con frecuencia y usando la replicación de la sesión solo para eso parece una exageración.

Answer 1

Creo que el único beneficio real es poder cerrar las instancias de Tomcat sin pensar mucho. Especialmente esto se aplica hoy en Cloud World (piense en las instancias de Amazon AWS) cuando los nodos pueden continuar con mucha frecuencia. La alternativa a esto sería comprar un equilibrador de carga decente que admite el drenaje de nodos. Pero los equilibradores de carga decentes son caros, y el drenaje lleva tiempo.

Otro escenario que puedo pensar es un carrito de compras (deficiente implementación) donde los artículos se mantienen en el HttpSession Y el cierre requeriría que el usuario vuelva a comprarlos (lo que probablemente conduciría a una venta perdida).

Pero en la mayoría de los casos, tiene razón: el beneficio de tener sesiones adhesivas y replicación de sesión es muy insignificante.

Answer 2

Como Mindas lo explicó antes:

Cuando usa LoadBalancing, significa que tiene varias instancias de Tomcat y necesita dividir las cargas.

• Si está utilizando la replicación de la sesión sin sesión pegajosa: Imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de Tomcat. Este usuario envía varias solicitudes a su aplicación, luego LoadBalancer enviará algunas de estas solicitudes a la primera instancia de Tomcat, y enviará algunas de estas solicitudes a la instancia de la segunda y otra al tercero.
• Si está usando una sesión adhesiva sin replicación: Imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de Tomcat. Este usuario envía varias solicitudes a su aplicación, luego LoadBalancer enviará la primera solicitud del usuario a una de las tres instancias de Tomcat, y todas las otras solicitudes que envían este usuario durante su sesión se enviarán a la misma instancia de Tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de Tomcat (instancia de Tomcat que se usa), el Bobalancer de carga envía las solicitudes restantes a otra instancia de Tomcat que aún se está ejecutando, pero como no usa la replicación de sesión, la instancia Tomcat que recibe Las solicitudes restantes no tienen una copia de la sesión del usuario, luego para este Tomcat, el usuario comienza una sesión: el usuario pierde su sesión y está desconectado de la aplicación web, aunque la aplicación web aún se está ejecutando.
• Si está utilizando una sesión pegajosa con replicación de sesión: Imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de Tomcat. Este usuario envía varias solicitudes a su aplicación, luego LoadBalancer enviará la primera solicitud del usuario a una de las tres instancias de Tomcat, y todas las otras solicitudes que envían este usuario durante su sesión se enviarán a la misma instancia de Tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de Tomcat (instancia de Tomcat que se usa), el Bobalancer envía las solicitudes restantes a otra instancia de Tomcat que aún se está ejecutando, mientras usa la replicación de sesión, la instancia Tomcat que recibe las solicitudes restantes tiene Una copia de la sesión del usuario, el usuario continúa en su sesión: el usuario continúa navegando por su aplicación web sin estar desconectado, el cierre de la instancia de Tomcat no afecta la navegación del usuario.

Answer 3

Solo para aclarar los problemas de configuración en JBoss 5.x en la configuración base "All" con MOD_JK. Establecer sesiones pegajosas en trabajadores. Archivo de propiedades

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

no previene la replicación de la sesión. Para desactivar la replicación de sesión en JBoss, necesitamos establecer $ jBoss_Home Server Your_node_Name Deploy Cluster JBoss-Cache-Manager.Sar Meta-Inf JBoss-Cache-Manager-JBoss.xmml cacheMode parámetro LOCAL.

Por lo general, en el escenario de sesión pegajosa no queremos la replicación de la sesión, ya que no queremos una sobrecarga adicional conectada con una cantidad significativa de operaciones de E/S necesarias para replicar sesiones.

De hecho, si vamos con sesiones adhesivas, no necesitamos ejecutar JBoss en la configuración "All", podríamos usar la configuración "predeterminada" o "estándar".

Lo único que debe hacerse es cambiar en $ jboss_home/server/your_node_name/implement/jbossweb.sar/server.xml:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">