Sessions collantes et non collantes

Question

Je veux connaître la différence entre les sessions collantes et non collantes. Ce que j'ai compris après avoir lu sur internet :

Sticky : il n'y aura qu'un seul objet de session.

Session non collante Objet de session pour chaque nœud de serveur

Answer 1

Lorsque votre site Web est desservi par un seul serveur Web, pour chaque paire client-serveur, un objet de session est créé et reste dans la mémoire du serveur Web. Toutes les demandes du client vont vers ce serveur web et mettent à jour cet objet de session. Si certaines données doivent être stockées dans l'objet de session pendant la période d'interaction, elles sont stockées dans cet objet de session et y restent tant que la session existe.

Toutefois, si votre site web est desservi par plusieurs serveurs web situés derrière un équilibreur de charge, ce dernier décide à quel serveur web (physique) chaque demande doit être adressée. Par exemple, s'il y a 3 serveurs web A, B et C derrière l'équilibreur de charge, il est possible que www.mywebsite.com est servi par le serveur A, www.mywebsite.com est servi par le serveur B et www.mywebsite.com / sont servis à partir du serveur C.

Maintenant, si les demandes sont servies à partir de trois serveurs différents (physiquement), chaque serveur a créé un objet de session pour vous et, comme ces objets de session se trouvent sur trois boîtes indépendantes, il n'y a aucun moyen direct pour l'un de savoir ce qui se trouve dans l'objet de session de l'autre. Afin de synchroniser les sessions de ces serveurs, vous devrez peut-être écrire/lire les données de la session dans une couche commune à tous, comme une base de données. Or, écrire et lire des données vers/depuis une BD pour ce cas d'utilisation n'est peut-être pas une bonne idée. C'est là qu'intervient le rôle de sticky-session .

Si l'équilibreur de charge reçoit l'instruction d'utiliser des sessions collantes, toutes vos interactions se feront avec le même serveur physique, même si d'autres serveurs sont présents. Ainsi, votre objet de session sera le même tout au long de votre interaction avec ce site Web.

En résumé, dans le cas de sessions collantes, toutes vos demandes seront dirigées vers le même serveur web physique, tandis que dans le cas d'un équilibreur de charge non collant, vous pouvez choisir n'importe quel serveur web pour répondre à vos demandes.

À titre d'exemple, vous pouvez lire des informations sur l'équilibreur de charge élastique d'Amazon et les sessions collantes ici : http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

Answer 2

J'ai fait une réponse avec plus de détails ici : https://stackoverflow.com/a/11045462/592477

Ou vous pouvez le lire ici ==>

Lorsque vous utilisez l'équilibrage de charge, cela signifie que vous avez plusieurs instances de tomcat et que vous devez répartir les charges.

• Si vous utilisez la réplication de session sans sticky session : Imaginez que vous n'avez qu'un seul utilisateur qui utilise votre application web, et que vous avez 3 instances de tomcat. Cet utilisateur envoie plusieurs requêtes à votre application, alors l'équilibreur de charge va envoyer certaines de ces demandes à la première instance de tomcat, et enverra certaines autres de ces demandes à la deuxième instance, et d'autres à la troisième.
• Si vous utilisez la session collante sans réplication : Imaginez que vous n'avez qu'un seul utilisateur qui utilise votre application web, et que vous avez 3 tomcat et que vous avez 3 instances tomcat. Cet utilisateur envoie plusieurs requêtes à votre application, alors le l'équilibreur de charge enverra la première demande de l'utilisateur à l'une des trois l'une des trois instances de tomcat, et toutes les autres demandes envoyées par cet par cet utilisateur pendant sa session seront envoyées à la même instance de tomcat. Pendant ces requêtes, si vous arrêtez ou redémarrez cette instance tomcat (l'instance de tomcat qui est utilisée), l'équilibreur de charge envoie les les demandes restantes à une autre instance de tomcat qui est toujours en cours d'exécution, MAIS comme vous n'utilisez pas la réplication de session, l'instance tomcat qui reçoit les demandes restantes n'a pas de copie de la session de l'utilisateur. session de l'utilisateur, alors pour ce tomcat l'utilisateur commence une session : l'utilisateur session : l'utilisateur perd sa session et est déconnecté de l'application web bien que bien que la web app soit toujours en cours d'exécution.
• Si vous utilisez la session collante AVEC la réplication de session : Imaginez que vous n'avez qu'un seul utilisateur qui utilise votre application web, et que vous avez 3 tomcat et que vous avez 3 instances tomcat. Cet utilisateur envoie plusieurs requêtes à votre application, alors le l'équilibreur de charge enverra la première demande de l'utilisateur à l'une des trois l'une des trois instances de tomcat, et toutes les autres demandes envoyées par cet par cet utilisateur pendant sa session seront envoyées à la même instance de tomcat. Pendant ces requêtes, si vous arrêtez ou redémarrez cette instance de tomcat (l'instance de tomcat qui est utilisée), l'équilibreur de charge envoie les demandes restantes à une autre instance de tomcat qui est toujours en cours d'exécution, comme vous utilisez la réplication de session, l'instance tomcat qui reçoit les requêtes restantes a une copie de la session de l'utilisateur alors l'utilisateur garde sa session : l'utilisateur continue à naviguer sur votre application web sans être déconnecté. sans être déconnecté, l'arrêt de l'instance tomcat n'a pas d'impact sur la navigation de l'utilisateur. n'a pas d'impact sur la navigation de l'utilisateur.