Persistencia de sesión de solución de equilibrio de carga de clúster web
1. Conceptos básicos
1. ¿Qué es Session?
La sesión debe denominarse "sesión" en la red y puede proporcionar la interacción necesaria entre el servidor y el sistema cliente. Debido a que el protocolo HTTP en sí mismo no tiene estado, a menudo es necesario proporcionar una solución para mantener el estado entre el servidor y el navegador a través de Session. La sesión es un espacio de almacenamiento del lado del servidor mantenido por el servidor de aplicaciones.Cuando un usuario se conecta al servidor, el servidor genera un ID de sesión único, que se utiliza como identificador para acceder al espacio de almacenamiento de la sesión del lado del servidor.
Los datos de SessionID se guardan en el cliente con Cookie. Cuando el usuario envía la página, SessionID se enviará al servidor para acceder a los datos de la sesión. El servidor también pasa el valor de SessionID a través de la reescritura de URL, por lo que no depende completamente de la cookie. Si la cookie del lado del cliente está deshabilitada, el servidor puede guardar automáticamente el valor de la sesión reescribiendo la URL, y este proceso es transparente para el programador.
2. ¿Qué es el uso compartido de sesiones?
Cuando la escala del negocio del sitio web y el número de visitas aumentan gradualmente, es posible que la estructura original del minisitio que consta de un solo servidor y un solo nombre de dominio ya no satisfaga las necesidades de desarrollo.
En este momento, podemos comprar más servidores y habilitar múltiples subdominios de segundo nivel de manera canalizada, y luego implementar el sitio web en servidores separados de acuerdo con las funciones comerciales, o mediante tecnologías de equilibrio de carga (como Haproxy, Nginx))) Permitir múltiples los canales comparten un conjunto de servidores.
Si implementamos los programas del sitio web en varios servidores por separado, y los separamos en varios nombres de dominio de segundo nivel, debido a las limitaciones del principio de implementación de la Sesión (la Sesión en PHP se guarda en forma de archivo en el disco duro del servidor local de forma predeterminada), esto Como resultado, los usuarios del sitio web a menudo tienen que ingresar nombres de usuario y contraseñas entre varios canales para iniciar sesión, lo que reduce considerablemente la experiencia del usuario. Además, el programa original puede leer directamente datos de las variables de sesión del usuario (como apodos, puntos, tiempo de inicio de sesión, etc.), porque las variables de sesión no se pueden actualizar entre servidores de forma síncrona, lo que obliga a los desarrolladores a leer y escribir la base de datos en formato real. tiempo, aumentando así la carga de la base de datos. Como resultado, la necesidad de resolver el problema del intercambio de sesiones entre servidores del sitio web se ha vuelto cada vez más urgente y, finalmente, han nacido una variedad de soluciones. Aquí hay cuatro soluciones más factibles para comparar y discutir.
1. Uso compartido de sesiones basado en cookies
Es posible que los lectores no estén familiarizados con este esquema, pero se ha utilizado habitualmente en grandes sitios web. El principio es cifrar la información de sesión de todos los usuarios en el sitio y colocarla bajo el nombre de dominio raíz (como: .host.com) en forma de cookies después de la serialización.
Cuando el navegador visita todos los sitios de dominio de segundo nivel bajo el nombre de dominio raíz, le pasará todas las características del contenido de la cookie correspondiente al nombre de dominio, para realizar el acceso compartido de la Sesión de Cookies del usuario entre múltiples servicios. .
La ventaja de este esquema es que no se requieren recursos de servidor adicionales. La desventaja es que debido a la limitación de la longitud del encabezado del protocolo HTTP, solo se puede almacenar una pequeña parte de la información del usuario. Al mismo tiempo, el contenido de la sesión cookieizada debe cifrarse y descifrarse (por ejemplo: utilizando DES, RSA, etc.) Realizar cifrado y descifrado de texto plano; MD5, SHA-1 y otros algoritmos para la autenticación antifalsificación). Además, también ocupará una cierta cantidad de recursos de ancho de banda, porque el navegador adjuntará la cookie local al encabezado HTTP y la pasará al servidor cuando solicite cualquier recurso bajo el nombre de dominio actual.
2. Uso compartido de sesiones basado en la base de datos
La primera opción es, por supuesto, la base de datos MySQL, y se recomienda utilizar la tabla de memoria Heap para mejorar la eficiencia de lectura y escritura de las operaciones de sesión. Esta solución tiene una gran viabilidad y ha sido ampliamente utilizada por todos, pero su desventaja es que las capacidades de lectura y escritura simultáneas de Session dependen del rendimiento de la base de datos MySQL. Al mismo tiempo, necesitamos implementar la lógica de eliminación de Session por nosotros mismos en para actualizar desde la tabla de datos con regularidad. Eliminando registros de sesión, cuando la concurrencia es demasiado alta, es probable que aparezcan bloqueos de tabla. Aunque podemos elegir un motor de tabla con bloqueos de nivel de fila, tenemos que admitir que usar una base de datos para almacenar Sessions sigue siendo un poco exagerado.
3. Copia de la sesión
Los amigos que estén familiarizados con Tomcat o Weblogic también deben estar familiarizados con la replicación de sesiones. Como su nombre indica, Session Copy es copiar la sesión del usuario a la Red. El aumento de los asuntos internos y el aumento exponencial de la fase negativa de la red trae este mecanismo de procesamiento. Pero sus deficiencias también son muy obvias: con el aumento en la cantidad de máquinas, la carga de la red aumenta exponencialmente y el rendimiento cae drásticamente con el aumento en la cantidad de servidores, y es fácil causar tormentas en la red.
4. Uso compartido de sesiones basado en Memcache / Redis
Memcache es un sistema de intercambio de memoria basado en la tecnología de E / S asíncrona multicanal de Libevent. El modo de almacenamiento de datos Key + Value simple hace que la lógica del código sea pequeña y eficiente, por lo que tiene una ventaja absoluta en las capacidades de procesamiento concurrente.
También vale la pena mencionar que Memcace P reduce la complejidad del código de eliminar datos de sesión caducados. Pero coincide con el mecanismo de caducidad de la sesión, que reduce la "solución de almacenamiento basada en la base de datos" para eliminar los datos caducados de la sesión. La lógica por sí sola genera una enorme presión de consulta en la tabla de datos.
Como estrella en ascenso de NoSQL, Redis a menudo se compara con memcached. Como estrella en ascenso de NoSQL, Redis a menudo se compara con memcached. Como caché, o simplemente llamado base de datos NoSQL, redis proporciona una gran cantidad de tipos de datos (lista, conjunto, etc.), que pueden liberar una gran cantidad de clasificación de datos desde la memoria de una sola máquina al clúster de redis para su procesamiento, y puede utilizarse para lograr un middleware de mensajes de nivel ligero. En la comparación de rendimiento entre memcached y redis, redis es mejor que memcached en velocidades de lectura y escritura de datos inferiores a: 100k. En nuestro sistema, redis ha reemplazado a memcached para almacenar datos de sesión.
3. ¿Qué es la persistencia de la sesión?
La retención de sesiones no es compartir sesiones.
En la mayoría de los sistemas de aplicaciones de comercio electrónico, o sistemas en línea que requieren autenticación de identidad de usuario, un cliente y un servidor a menudo pasan por varias interacciones antes de completar una transacción o una solicitud. Dado que estas interacciones están estrechamente relacionadas, en el proceso de estas interacciones, el servidor a menudo necesita comprender los resultados del procesamiento de la interacción anterior o los resultados de la interacción de los pasos anteriores para completar un determinado paso de interacción, que requiere todo lo relevante. El proceso lo completa un servidor y el equilibrador de carga no puede distribuirlo a diferentes servidores.
Y esta serie de procesos de interacción relacionados puede completarse mediante múltiples sesiones de una conexión entre el cliente y el servidor, o puede completarse mediante múltiples sesiones en múltiples conexiones diferentes entre el cliente y el servidor. Con respecto a varias sesiones de diferentes conexiones, el ejemplo más típico es el acceso basado en HTTP. Un cliente puede necesitar hacer clic varias veces para completar una transacción, y una solicitud generada por un nuevo clic puede reutilizar la conexión establecida por el clic anterior. Puede también será una conexión recién creada.
La persistencia de la sesión significa que existe un mecanismo en el balanceador de carga que puede identificar la relevancia del proceso de interacción entre el cliente y el servidor. Mientras realiza el balanceo de carga, también puede garantizar que una serie de solicitudes de acceso relacionadas se asignen al mismo. .En el servidor.
En segundo lugar, el mecanismo de retención de sesiones del equilibrador de carga (enfoque de entrevista)
El propósito del mecanismo de retención de sesiones es garantizar que un determinado usuario y sesión del sistema solo se entregue al mismo servidor para su procesamiento dentro de un período de tiempo determinado. Esto es particularmente importante cuando se satisfacen las necesidades de banca en línea, compras en línea y otras escenarios de aplicación. El balanceador de carga implementa la retención de sesiones; por lo general, existen varias soluciones:
1. Mantenimiento continuo basado en la dirección IP de origen. Se utiliza principalmente para el equilibrio de carga de cuatro capas. Esta solución debería ser la más familiar para todos. LVS / HAProxy y Nginx tienen mecanismos de procesamiento similares, como el algoritmo ip_hash en Nginx y el algoritmo fuente en HAProxy.
2. Mantenimiento continuo basado en datos de cookies. Se utiliza principalmente para el equilibrio de carga de la capa 7 para garantizar que los paquetes de la misma sesión se puedan distribuir al mismo servidor. Entre ellos, según si el mensaje de respuesta del servidor lleva el campo Establecer cookie que contiene información del servidor, se puede dividir en inserción y retención de cookies e intercepción y retención de cookies.
3. Mantenimiento continuo basado en encabezado HTTP. Se utiliza principalmente para el balanceo de carga de siete capas. Cuando el balanceador de carga recibe la primera solicitud de un determinado cliente, establecerá una entrada persistente basada en las palabras clave del encabezado HTTP y registrará el estado del servidor asignado al cliente. la entrada de sesión Durante la vida útil de, las conexiones posteriores con la misma información de encabezado HTTP se enviarán al servidor para su procesamiento.
3. Caso práctico de mecanismo de retención de sesiones de LvS (enfoque de entrevista)
Mecanismo de retención de sesión LVS
LVS usa la configuración == persistencia (en segundos) == en el archivo de configuración para establecer el tiempo de retención de la sesión. Esta opción es especialmente importante para los sitios web de comercio electrónico: cuando los usuarios inician sesión en el sitio web con una cuenta de forma remota, pasan esta sesión La función de retención puede reenviar la solicitud del usuario al mismo servidor de aplicaciones. Hagamos una suposición aquí: asumiendo que hay un entorno LVS, usando el modo de reenvío LVS / DR, hay dos servidores web reales y el balanceador de carga LVS no habilita la función de persistencia de la sesión. Cuando el usuario visita por primera vez, el equilibrador de carga reenvía su solicitud de acceso a un servidor real, y luego verá una página de inicio de sesión y la primera visita está completa. Luego, ingresa el nombre de usuario y la contraseña en el cuadro de inicio de sesión y luego los envía. En este momento, puede surgir el problema: el inicio de sesión no se realizó correctamente. Debido a que no hay retención de sesión, el equilibrador de carga puede reenviar la segunda solicitud a otro servidor, de modo que el navegador le recordará al cliente que debe volver a hacerlo.
Caso de combate real
Conexión persistente basada en host
Cuando cada cliente es persistente; todas las solicitudes de un mismo cliente se dirigen al RS previamente seleccionado; es decir, mientras la IP sea la
misma, el servidor asignado es siempre el mismo
ipvsadm -A -t 172.16.0.8:0 -s wlc -p 120
# 添加一个 tcp 负载集群，集群地址为 172.16.0.8 ，算法为 wlc，持久化时间为 120s
Conexión persistente basada en puerto
Cuando cada puerto es persistente; las solicitudes del mismo cliente para el mismo servicio (puerto) siempre se dirigirán al RS previamente seleccionado
ipvsadm -A -t 172.16.0.8:80 -s rr -p 120
# 添加一个 tcp 负载集群，集群地址为 172.16.0.8:80 ，算法为 wlc，持久化时间为 120s
Conexión persistente basada en firewall
Las solicitudes del mismo cliente para un servicio (puerto) específico siempre se dirigen al RS seleccionado; sin embargo, puede definir dos puertos no relacionados como un servicio de clúster.
iptables -t mangle -A PREROUTING -d 172.16.0.8 -p tcp --dport 80 -j MARK --
set-mark 10 # 添加一个防火墙规则，当目标地址为 172.16.0.8 并且 目标端口为 80 时给数据包打一个标记，设置mark 值为 10
iptables -t mangle -A PREROUTING -d 172.16.0.8 -p tcp --dport 443 -j MARK --
set-mark 10
# 添加一个防火墙规则，当目标地址为 172.16.0.8 并且 目标端口为 443 时给数据包打一个标记，设置mark 值为 10
service iptables save # 保存防火墙规则持久化生效
ipvsadm -A -f 10 -s wlc -p 120 # 添加一个负载调度器，当 mark 值为 10 时进行负载均衡使用wlc 算法，持久化生效时间为 120s