Aplicación web de equilibrio de carga

Question

Hay servidores web Tomcat con carga equilibrada.Cada solicitud podría ser atendida por un servidor Tomcat diferente.

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

Answer 1

En primer lugar, querrá configurar su balanceador de carga para afinidad de sesión/sesiones fijas, de modo que continúe reenviando todas las solicitudes al mismo Tomcat (siempre que esté activo) según JSESSIONID.

El documento de agrupación en clústeres de Tomcat establece dos requisitos importantes para que su aplicación tenga exitosamente replicadas sus sesiones:

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

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

(En realidad, creo que todos estos puntos se aplican independientemente del contenedor de servlet que esté utilizando).

Actualizar: Para abordar algunas de las preguntas en los comentarios sobre por qué usar sesiones fijas cuando se equilibra la carga entre varios servidores, creo que es más fácil explicar esto con un ejemplo.

En primer lugar, esto sólo importa realmente si su aplicación mantiene algún tipo de datos durante la sesión, lo que puede no ser de todas las aplicaciones (aunque probablemente sea la mayoría).Si no mantiene los datos durante la sesión, probablemente no le importe nada de esto y puede dejar de leer aquí.

Tener un entorno donde mantienes los datos en sesión pero lo haces no Tener una sesión fija te 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 sucede que lee este mismo atributo de sesión.Puede configurar Tomcat para replicar datos de sesión en todos los servidores del clúster, pero esta replicación no ocurre instantáneamente.¿Qué pasa si la solicitud inicial de first.jsp es manejado por server1 y un nanosegundo después de que se completa, el mismo visitante hace una solicitud para second.jsp, que en su entorno no pegajoso es manejado 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 todo el clúster?Esto se convertiría en un dolor gigante.

La configuración de sesiones fijas o de afinidad de sesión elimina este dolor de cabeza;Al tener todas las solicitudes del mismo servidor de cliente por el mismo nodo, no tiene que preocuparse por "¿Este nodo está actualizado cuando maneja la solicitud?" Cuando el nodo falla, el cliente aún puede conmutación por error a otro nodo en el clúster, que tiene una copia de sus datos de sesión, pero con sesiones pegajosas se convierte en el caso raro y no la norma.

Hay otra razón para querer sesiones fijas:carga entre los nodos del clúster.Si cualquier nodo pudiera manejar una solicitud en una sesión, eso implicaría que tiene una replicación total configurada en el clúster (lo que significa que los datos de la sesión del nodo1 se replican en el nodo2, nodo3, ..., nodo N, los datos de la sesión del nodo2 se replican en el nodo1, nodo3, ...ninguno N, etc.).La replicación de sesiones totales puede consumir mucho ancho de banda y recursos cuando el clúster crece, 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 replicar los datos de un nodo solo a unos pocos "amigos" en el clúster, de modo que, en caso de que el nodo falle, sus datos estén disponibles en otro lugar, pero sin que cada nodo tenga que tener una copia.En este escenario, configuraría el clúster para que el nodo1 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 de todos para todos.