session - juego - Sesiones adhesivas y no adhesivas

session kickstarter

Question

Quiero saber la diferencia entre las sesiones adhesivas y las no adhesivas. Lo que entendí después de leer desde internet:

Adherido : solo el único objeto de sesión estará allí.

Sesión no adhesiva : objeto de sesión para cada nodo del servidor

Answer 1

He respondido con algunos detalles más aquí: https://.com/a/11045462/592477

O puedes leerlo allí ==>

Cuando utiliza el balanceo de carga, significa que tiene varias instancias de tomcat y necesita dividir las cargas.

• Si está utilizando la replicación de sesión sin una sesión fija: imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego loadbalancer enviará algunas de estas solicitudes a la primera instancia de tomcat y enviará alguna otra de estas solicitudes a la segunda instancia, y otras a la tercera.
• Si está utilizando una sesión fija sin replicación: imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego loadbalancer enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que envíe este usuario durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de tomcat (instancia de tomcat que se utiliza), loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, PERO como usted no usa la replicación de sesión, la instancia de tomcat que recibe las solicitudes restantes no tienen una copia de la sesión del usuario, entonces para este tomcat el usuario comienza una sesión: el usuario pierde su sesión y se desconecta de la aplicación web aunque la aplicación web aún se está ejecutando.
• Si está utilizando una sesión fija con la replicación de sesión: imagine que solo tiene un usuario que usa su aplicación web y tiene 3 instancias de tomcat. Este usuario envía varias solicitudes a su aplicación, luego loadbalancer enviará la primera solicitud de usuario a una de las tres instancias de tomcat, y todas las demás solicitudes que envíe este usuario durante su sesión se enviarán a la misma instancia de tomcat. Durante estas solicitudes, si apaga o reinicia esta instancia de tomcat (instancia de tomcat que se usa), loadbalancer envía las solicitudes restantes a otra instancia de tomcat que aún se está ejecutando, ya que utiliza la replicación de sesión, la instancia de tomcat que recibe las solicitudes restantes tiene una copia de la sesión del usuario luego el usuario mantiene su sesión: el usuario continúa navegando en su aplicación web sin desconectarse, el cierre de la instancia de tomcat no afecta la navegación del usuario.

Answer 2

Cuando su sitio web es servido por solo 1 web server , para cada par, se crea un objeto de sesión y permanece 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 encuentran detrás de un 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 están siendo atendidas desde (físicamente) 3 servidores diferentes, cada servidor ha creado un objeto de sesión para usted y dado que estos objetos de sesión se encuentran en 3 cuadros independientes, no hay manera directa de saber 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 papel de la sesión adhesiva . Si se le ordena al load balancer que use 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.

Para resumir, en el caso de las Sesiones Adheridas, todas sus solicitudes se dirigirán al mismo servidor web físico, mientras que en el caso de un desequilibrado loadbalancer puede elegir cualquier servidor web para atender sus solicitudes.

Como ejemplo, puede leer acerca de Elastic Load Balancer de Amazon y las sesiones adhesivas aquí: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html