Sessions collantes et non collantes
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: seul un objet de session sera présent.
session non collante: objet de session pour chaque nœud de serveur
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 sur ce serveur Web et mettent à jour cet objet de session. Si certaines données doivent être stockées dans l'objet de session au cours de 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, celui-ci détermine le serveur Web réel (physique) auquel chaque demande doit accéder. 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/index.jsp soit servi à partir du serveur A, www.mywebsite.com/login.jsp le serveur B et www.mywebsite.com/accoutdetails.php sont desservis par le serveur C.
Maintenant, si les demandes sont traitées par (physiquement) 3 serveurs différents, chaque serveur a créé un objet de session pour vous et, comme ces objets de session reposent sur trois boîtes indépendantes, il n'y a aucun moyen direct de savoir ce qu'il y a dans l'objet de session. de l'autre. Afin de synchroniser ces sessions de serveur, vous devrez peut-être écrire/lire les données de la session dans une couche commune à tous, comme une base de données. Écrire et lire des données depuis/vers une base de données pour ce cas d'utilisation peut ne pas être une bonne idée. Maintenant, voici le rôle de sticky-session .
Si vous demandez à l'équilibreur de charge d'utiliser des sessions persistantes, toutes vos interactions auront lieu 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.
Pour résumer, 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 loadbalancer non collant, vous pourrez choisir un serveur Web pour répondre à vos demandes.
À titre d'exemple, vous pouvez lire des informations sur Elastic Load Balancer d'Amazon et les sessions collantes d'Amazon ici: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions .html
J'ai fait une réponse avec quelques détails supplémentaires 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 diviser les charges.
- Si vous utilisez une réplication de session sans session collante: Imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous ayez 3 instances de Tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis le répartiteur de charge envoie certaines de ces demandes à la première instance de Tomcat, et certaines autres à la deuxième instance.
- Si vous utilisez une session collante sans réplication: Imaginez qu'un seul utilisateur utilise votre application Web et que vous ayez 3 instances de Tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis le répartiteur de charge envoie la première demande à l'une des trois instances de Tomcat. Toutes les autres demandes envoyées par cet utilisateur au cours de sa session seront envoyées à la même instance de Tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance Tomcat (instance Tomcat utilisée), le loadbalancer envoie les demandes restantes à une autre instance Tomcat toujours en cours d'exécution, MAIS vous n'utilisez pas la réplication de session, l'instance Tomcat qui reçoit les demandes restantes ne possèdent pas de copie de la session de l'utilisateur, puis pour ce Tomcat, l'utilisateur commence une session: l'utilisateur perd sa session et est déconnecté de l'application Web alors que celle-ci est toujours en cours d'exécution.
- Si vous utilisez une session collante AVEC la réplication de session: Imaginez que vous n'avez qu'un seul utilisateur utilisant votre application Web et que vous ayez 3 instances de Tomcat. Cet utilisateur envoie plusieurs demandes à votre application, puis le répartiteur de charge envoie la première demande à l'une des trois instances de Tomcat. Toutes les autres demandes envoyées par cet utilisateur au cours de sa session seront envoyées à la même instance de Tomcat. Au cours de ces demandes, si vous arrêtez ou redémarrez cette instance Tomcat (instance Tomcat utilisée), le loadbalancer envoie les demandes restantes à une autre instance Tomcat toujours en cours d'exécution. Lorsque vous utilisez la réplication de session, l'instance Tomcat qui reçoit les demandes restantes a une copie de la session de l'utilisateur que l'utilisateur conserve ensuite: l'utilisateur continue de naviguer dans votre application Web sans être déconnecté, la fermeture de l'instance de Tomcat n'a aucune incidence sur la navigation de l'utilisateur.