Compatibilidad con sesiones de Java en varios sitios
NCache proporciona persistencia de sesión en varios sitios que se puede utilizar para administrar sesiones de servlet Java en varias granjas de servidores web (que están separadas geográficamente) si no desea replicar sesiones en la WAN debido a los costos de consumo de ancho de banda.
Para comprender la persistencia de sesiones en múltiples sitios, considere las aplicaciones de servlet Java que se ejecutan en granjas de servidores web con equilibrio de carga que abarcan múltiples regiones. Un Load Balancer puede redirigir a los clientes a diferentes regiones según el tráfico de usuarios. Para almacenar en caché las sesiones de Java, se requiere una caché en clúster para que las sesiones se repliquen entre regiones. Es posible que este enfoque no sea adecuado debido a la replicación de sesiones en la WAN. Además, puede generar problemas de rendimiento porque los nodos de almacenamiento en caché están separados geográficamente.
NCache Sesiones Java multisitio
Para solucionar estos problemas, NCache presenta el concepto de sesiones multisitio. El almacenamiento en caché de las sesiones en una aplicación de granjas web separadas geográficamente requiere configurar cachés independientes en cada región. Supongamos que tiene cuatro regiones, cada una configurada con cachés independientes como CR-1, CR-2, CR-3 y CR-4. Cada caché agrupada tiene su propio conjunto de clientes (servlet Java) como una granja web. Cada cliente configurará el NCache filtro de servlet de sesión. Debe especificar el caché principal (caché de la región actual) y un conjunto de cachés secundarios (lista de cachés de otras regiones) junto con los prefijos definidos por el usuario para cada nombre de caché.
Esta configuración se carga tras la inicialización del NCache filtro de proveedor de sesión. De esta forma, cada cliente estará al tanto de los cachés en otras regiones. El ID de sesión creado por el NCache El proveedor de sesión es según el prefijo de caché principal de cada región, es decir, el prefijo del caché principal se agrega a los ID de sesión de esa región. Estos clientes agregarán, actualizarán y obtendrán sesiones principalmente desde su propia caché agrupada, es decir, la caché principal. Sin embargo, en ocasiones, es posible que se envíe una solicitud de cliente a la granja web de otra ubicación geográfica para equilibrar la carga. Ahora, NCache identificará la solicitud a partir de su prefijo de caché principal y permitirá que las solicitudes del usuario accedan a la misma sesión desde el caché anterior.
Para comprender esto, considere una ruta de solicitud a una granja web de la caché de la región CR-2. En esta situación, NCache extrae el prefijo de ID de sesión que será CR-1 y buscará su ID de caché en su propia lista de cachés secundarios. Como todos los clientes de la región tendrán un conjunto de cachés de todas las demás regiones como cachés secundarios, NCache recuperará esta sesión del caché CR-1. NCache actualizará el ID de esta sesión agregando su prefijo de caché principal actual, es decir, CR-2, y actualizándolo en el caché principal actual (CR-2) para atender solicitudes futuras.
Supongamos que un cliente realiza una solicitud que pasa por el Load Balancer. Supongamos que la solicitud de sesión pasa al servidor web1 dentro de una granja de servidores web según la carga del sistema. Una vez que llega la solicitud, se crea una sesión con el prefijo del servidor web1 agregado al ID de la sesión y se guarda en la caché principal de esta granja de servidores web, en este caso, caché replicada1.
Cuando Load Balancer enruta el mismo cliente a Web Farm2, NCache analiza el prefijo de sesión. Con la ayuda de este prefijo, recupera la sesión de Replicated Cache1 aunque pertenezca a Web Farm1. Esto le permite tener dos o más centros de datos activos y mantener la mayor parte del tráfico en su propio centro de datos, pero ocasionalmente desbordarse a otros centros de datos si es necesario. También puede cerrar uno de los centros de datos sin causar interrupciones a los usuarios porque otros centros de datos podrán acceder a sus sesiones. O podemos decir que si una de las granjas web deja de funcionar por cualquier motivo, otras granjas web comenzarán a acceder a las sesiones de los usuarios desde la caché de esa región y, finalmente, todos los datos de la sesión se moverán a la caché de la siguiente región para evitar perder la sesión. datos.
NCache proporciona una opción de cambio sin código para que las aplicaciones web basadas en Java almacenen sesiones en NCache implementando el módulo de sesión nc-sessionprovider.jar como un filtro de servlet JSP. Usar el NCache Módulo de sesión Java, debe ejecutar un contenedor (servidor web) compatible con Servlet 2.3+. El usuario sólo necesita hacer referencia a algunas bibliotecas y agregar un filtro en el web.xml de la aplicación para que todas las solicitudes lleguen a la aplicación a través de NCache. Se admiten las siguientes plataformas J2EE/Jakarta:
- Gato
- JBoss/WildFly
- lógica web
- WebSphere
Para obtener más información sobre cómo configurar el módulo de sesión multisitio, consulte Proveedor de estado de sesión multisitio.
Vea también
Resumen conceptual
Configuración de aplicaciones para utilizar el módulo de sesión de Java
Registro de errores