Procesamiento de sesiones en entorno de clúster

En el caso de un solo servidor, el procesamiento de la sesión es relativamente simple. Una vez en un entorno de clúster, debemos considerar los problemas del usuario y la sesión. Si no se procesa, una vez que se cambia el sondeo de IP del backend, las cookies de sesión. se perderá. No se puede encontrar la sesión y la sesión se interrumpe. En este escenario, suelen existir las siguientes 5 soluciones.

Vincula cada usuario al servidor back-end para que la sesión del usuario siempre esté en el mismo servidor. Esta es la solución de menor costo y solo requiere modificar la configuración del servidor Nginx. Si es sobre una arquitectura más antigua, se recomienda este plan de transformación.

Esta solución también tiene limitaciones, por ejemplo, si un servidor falla y cambia a otro servidor, se perderá la sesión correspondiente. Hay otro problema si se utiliza una CDN en el extremo frontal, la frecuencia de los cambios de IP del cliente puede ser muy alta. Puede cambiar una vez por hora o menos. Esto es fácil de suceder en un entorno de red de campus.

Como sugiere el nombre, la replicación de sesiones permite que cada servidor del clúster almacene todas las sesiones en todos los servidores de todo el clúster. De esta forma, una vez que un determinado servidor cuelga, los usuarios pueden acceder a los mismos datos de sesión cuando cambian a otros servidores. La desventaja de esta solución es que la replicación de sesiones requiere una sobrecarga de red y recursos del sistema adicionales. Este problema es particularmente obvio cuando hay muchos servidores o una gran cantidad de datos almacenados en la sesión.

La operación de replicación de sesiones en sí es relativamente complicada, pero para el servidor, la configuración es relativamente simple, pero el rendimiento es un gran problema. Se vuelve más difícil cuando el número de servidores en el clúster es mayor que dos. En resumen, esta es una solución temprana.

La solución fija es similar a la solución 1, pero puede fijar la sesión a uno de los servidores. Es un complemento de la solución 1 y puede evitar la pérdida de sesión causada por conflictos de IP bajo fluctuaciones de la red CDN. . Pero todavía no puede resolver el problema de la pérdida de sesión causada por el bloqueo del servidor.

La solución de almacenamiento centralizado de sesiones basada en NoSQL como Redis es actualmente la solución más popular. Al principio, se usaba MySQL para el almacenamiento. Además de aumentar la complejidad del sistema, la solución de introducir Redis todavía tiene los siguientes problemas:

Utilice cookies puras, no utilice sesiones y se distribuya de forma natural. Problemas:

Cabe señalar que si la aplicación necesita "prohibir inicios de sesión simultáneos", será mucho más problemático utilizar cookies para solucionarlo.

Además, puede convertir la cookie en un token para verificar al usuario y traer el token con cada solicitud como credencial de sesión.