Aplicación web de balance de carga

Question

Hay servidores web tomcat con equilibrio de carga. Cada solicitud puede ser servida por un servidor Tomcat diferente.

¿Cómo podríamos ocuparnos de esto mientras escribimos el código para la aplicación web basada en j2ee (struts)?

Answer 1

En primer lugar, deberá configurar su equilibrador de carga para afinidades de sesión/sesiones adhesivas, para que continúe reenviando todas las solicitudes al mismo Tomcat (siempre que esté activo) en base a JSESSIONID.

The Tomcat clustering doc establece dos requisitos importantes para su aplicación tenga éxito se replica sesiones:

• Todos los atributos de la sesión deben implementar java.io.Serializable
• Asegúrese de que su web.xml tiene el elemento <distributable/> o ajustadas en la <Context distributable="true" />

Si comienza a poner objetos en la sesión que no implementan Serializable (o que tienen propiedades/campos que no implementan Serializable), entonces tendrá problemas.

(todo aplicar realmente estos puntos, independientemente del contenedor de servlets que está utilizando, creo.)

Actualización: Para hacer frente a algunas de las preguntas en los comentarios acerca de por qué utilizar las sesiones problemáticas cuando se está equilibrando la cargar entre varios servidores, creo que es más fácil explicar esto con un ejemplo.

En primer lugar, esto solo importa si su aplicación conserva algún tipo de datos durante la sesión, que puede no ser una aplicación individual (aunque probablemente sea la mayoría). Si no mantiene los datos en sesión, probablemente no le importe nada de esto y puede dejar de leer aquí.

Tener un entorno en el que se guardan los datos en la sesión pero lo hace no tener sesión fija abriría un mundo de dolores de cabeza.

Digamos first.jsp actualiza algún valor en un atributo de sesión particular, y second.jsp pasa a leer este mismo atributo de sesión. Puede configurar Tomcat para replicar los datos de la sesión en todos los servidores del clúster, pero esta replicación no se produce al instante. ¿Qué pasa si la solicitud inicial de first.jsp es manejada por y un nanosegundo después de que se complete, el mismo visitante hace una solicitud al second.jsp, que en su entorno no adherente se maneja por server2. Dado que la replicación no es instantánea, ¿tiene alguna forma de saber si está leyendo los datos de sesión más actualizados? ¿Tiene que agregar algún tipo de lógica para sincronizar sus lecturas en el clúster? Esto se convertiría en un dolor gigante.

La configuración de sesión afín/sesiones adhesivas elimina este dolor de cabeza; al tener todas las solicitudes del mismo nodo del cliente desde el mismo servidor, no tiene que preocuparse por "¿este nodo está actualizado para el momento en que maneja la solicitud?" Cuando el nodo falla, el cliente puede conmutar por error a otro nodo del clúster, que tiene una copia de sus datos de sesión, pero con las sesiones adhesivas esto se convierte en el caso raro y no en la norma.

Hay otra razón para querer sesiones adhesivas: cargar entre los nodos en el clúster.Si un nodo puede manejar una solicitud en una sesión, eso implicaría que tiene una replicación completa en el clúster (lo que significa que los datos de la sesión del nodo 1 se repiten en el nodo 2, el nodo 3, ..., el nodo N, los datos de sesión de node2 se replican en node1, node3, ... none N, etc.). La replicación de sesión completa puede convertirse en un uso intensivo de ancho de banda y recursos cuando el clúster se agranda, porque cada adición al clúster significa otro nodo más que necesita comunicarse con todos los demás nodos del clúster.

Una alternativa a esto es copiar los datos de un nodo a solo unos pocos "amigos" en el clúster, de modo que en caso de que el nodo falle, los datos están disponibles en otra parte pero sin que cada nodo tenga una copia. En este escenario, debe configurar el clúster para que el nodo 1 tenga sus datos replicados en los nodos 2 y 3, el nodo 2 tenga sus datos replicados en los nodos 3 y 4, etc., formando una cadena. En este escenario, agregar nodos adicionales al clúster no hace que la cantidad de comunicación entre nodos aumente rápidamente, como ocurre en un esquema todo-en-todos.