Cuando su sitio web es servido por solamente 1 web server
, para cada par, un objeto de sesión se crea y se mantiene en la memoria del servidor web. Todas las solicitudes del cliente van a este servidor web y actualiza este objeto de sesión. Si es necesario almacenar algunos datos en el objeto de sesión durante el período de interacción, se almacenan en este objeto de sesión y permanecen allí mientras exista la sesión.
Sin embargo, si su sitio web es servido por multiple web servers
que se encuentra detrás de load balancer
, el equilibrador de carga decide a qué servidor web real (físico) debe dirigirse cada solicitud. Por ejemplo, si hay 3 servidores web A, B y C detrás del equilibrador de carga, es posible que www.mywebsite.com/index.jsp se publique desde el servidor A, www.mywebsite.com/login.jsp se sirve desde el servidor B y www.mywebsite.com/accoutdetails.php se sirven desde el servidor C.
Ahora, si las solicitudes se sirven desde (físicamente) 3 servidores diferentes, cada servidor ha creado un objeto de sesión para usted y porque estas sesiones los objetos se sientan en 3 casilleros independientes, no hay forma directa de que uno sepa qué hay en el objeto de sesión del otro. Para sincronizar estas sesiones de servidor, puede que tenga que escribir/leer los datos de la sesión en una capa que es común a todos, como una base de datos. Ahora, escribir y leer datos a/desde un DB para este caso de uso puede no ser una buena idea. Ahora, aquí viene el rol de pegada a la sesión. Si el load balancer
recibe instrucciones para utilizar sesiones adhesivas, todas sus interacciones se realizarán con the same physical server
, aunque haya otros servidores presentes. Por lo tanto, su objeto de sesión será el mismo durante toda su interacción con este sitio web.
En resumen, en el caso de las Sesiones autoadhesivas, todas sus solicitudes se dirigirán al mismo servidor web físico, mientras que en el caso de un dispositivo de carga no adhesivo, puede elegir cualquier servidor web para atender sus solicitudes.
A modo de ejemplo, se puede leer sobre elástico equilibrador de carga de Amazon y sesiones pegajosa aquí: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
@ TJ- ¿Qué pasará si un nodo no está disponible? – gstackoverflow
En la mayoría de los casos, la sesión se perderá. En el caso de [AWS ESB] (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html) _Si una instancia falla o se vuelve no saludable, el equilibrador de carga detiene la solicitud de enrutamiento a esa instancia, en su lugar elige una nueva instancia saludable basada en el algoritmo de equilibrio de carga existente. El equilibrador de carga trata la sesión como ahora "pegada" a la nueva instancia sana y continúa enrutando las solicitudes a esa instancia, incluso si la instancia fallida regresa._ –
¿De acuerdo con qué información LoadBalancer hace que una sesión HTTP permanezca fija? Especialmente en conexiones HTTPS, este tema se vuelve interesante. ¿Alimenta al LB con la clave privada de los servidores web, de modo que puede romper la conexión SSL y buscar la sesión HTTP? ¿O el LB simplemente hace uso de la dirección IP del cliente? En este caso, ¿qué pasa con el servidor proxy donde varios clientes usan la misma dirección IP? ¿O peor aún, clientes móviles, donde la dirección IP cambia con frecuencia? ¿O hay incluso una mejor técnica para eso? Gracias – g000ze