Session collante et réplication de Session
je suis en train d'évaluer le cas de l'utilisation de sessions collantes avec réplication de Session dans tomcat. D'après mon évaluation initiale, j'ai pensé que si nous activons la réplication de Session, alors la session commencée dans un noeud tomcat sera copiée sur tous les autres noeuds tomcat et donc nous n'avons pas besoin de session collante pour continuer les sessions et la requête peut être récupérée par n'importe quel noeud.
mais il semble que la réplication de session est en général utilisée avec les sessions collantes, sinon l'id de session doit être changé à chaque fois que la requête va à un autre noeud. réf: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node
est-ce que quelqu'un peut expliquer quelle est l'utilisation réelle de la réplication de session si vous devez activer sticky session? Parce qu'alors vous copiez inutilement la session sur chaque noeud, quand la requête avec un id de session donné va toujours vers le même noeud. Il pourrait être bénéfique en cas de crash d'un noeud, mais alors cela ne se produit pas souvent et l'utilisation de la réplication de session uniquement pour cela semble exagérée.
3 réponses
je pense que le seul avantage réel est de pouvoir désactiver les instances Tomcat sans trop réfléchir. Cela s'applique particulièrement aujourd'hui dans le monde des nuages (pensez Amazon AWS spot instances) lorsque les noeuds peuvent aller et venir très souvent. Une Alternative à cela serait d'acheter un équilibreur de charge décent qui soutient le drainage de noeud. Mais les équilibreurs de charge décents sont chers, et drainer prend du temps.
un autre scénario que je peux penser est un (mauvaise mise en œuvre de) panier où les articles sont gardés dans le HttpSession et la fermeture exigerait que l'utilisateur les rachète (ce qui entraînerait probablement une perte de vente).
mais dans la plupart des cas vous avez raison - l'avantage d'avoir à la fois des sessions collantes et la réplication de session est très négligeable.
Mindas a expliqué à l'avant :
lorsque vous utilisez loadbalancing cela signifie que vous avez plusieurs instances de tomcat et que vous devez diviser les charges.
- si vous utilisez la réplication de session sans session collante: Imaginez que vous n'ayez qu'un seul utilisateur utilisant votre application web, et que vous ayez 3 Tomcat instances. Cet utilisateur envoie plusieurs requêtes à votre application, le loadbalancer enverra certaines de ces requêtes au premier tomcat exemple, et envoyer d'autres de ces demandes à la deuxième exemple, et d'autres à la troisième.
- si vous utilisez sticky session sans réplication: Imaginez que vous n'ayez qu'un seul utilisateur utilisant votre application web, et que vous ayez 3 tomcat instance. Cet utilisateur envoie plusieurs requêtes à votre application, puis la loadbalancer enverra la première demande d'utilisateur à l'un des trois les instances tomcat, et toutes les autres requêtes qui sont envoyées par ce utilisateur pendant sa session sera envoyé à la même tomcat instance. Pendant ces requêtes, Si vous fermez ou redémarrez ce tomcat instance (Tomcat instance qui est utilisée) le loadbalancer envoie le demandes restantes à une autre instance 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 requêtes restantes n'a pas de copie de la session de l'utilisateur alors pour ce tomcat l'utilisateur commence une session: le l'utilisateur lâche sa session et est déconnecté de l'application web bien que l'application web est encore exécuter.
- si vous utilisez sticky session avec la réplication de session: Imaginez que vous n'ayez qu'un seul utilisateur utilisant votre application web, et que vous ayez 3 tomcat instance. Cet utilisateur envoie plusieurs requêtes à votre application, puis la loadbalancer enverra la première demande d'utilisateur à l'un des trois les instances tomcat, et toutes les autres requêtes qui sont envoyées par ce l'utilisateur pendant sa session sera envoyé à la même instance tomcat. Pendant ces requêtes, Si vous arrêtez ou redémarrez ceci tomcat instance (Tomcat instance qui est utilisée) le loadbalancer envoie le demandes restantes à une autre instance tomcat qui est toujours en lançant, comme 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, puis l'Utilisateur continue sur sa session : l'Utilisateur continue à parcourir votre web app sans être déconnecté, l'arrêt de l'instance tomcat n'a pas d'incidence sur la navigation de l'utilisateur.
juste pour clarifier les problèmes de configuration sur JBoss 5.X dans la configuration de base" all " avec mod_jk. Réglage collant séances chez les travailleurs.fichier de propriétés
worker.list=loadbalancer
... nodes configuration omitted
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=True
n'empêche pas la réplication de session. Pour désactiver la réplication de session sur JBoss, nous devons définir $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode paramètre LOCAL.
habituellement dans le scénario de session collante nous ne vouloir la réplication de session, puisque nous ne voulons pas de frais généraux supplémentaires reliés à une quantité importante d'opérations D'E/S nécessaires pour répliquer les sessions.
en fait, si vous utilisez des sessions sticky, nous n'avons pas besoin d'exécuter JBoss dans la configuration "all", nous pouvons utiliser la configuration "default" ou "standard".
la seule chose à faire est de changer dans $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/serveur.xml:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">