J'essayais de décider ce qui est mieux dans un mode proxy inverse Tomcat + Apache pour la réplication de session. Qu'est-ce qui est le plus commun sur les déploiements? réplication de session ou session de bâton? Y a-t-il des inconvénients pour la réplication de session?Quels sont les inconvénients de la réplication de session sur Tomcat?
Merci
Je peux signaler les considérations suivantes si vous allez pour la réplication de session.
Performance
L'inconvénient principal sera sur la performance. Les sessions répliquées impliquent la copie des données de session sur tous les serveurs du cluster. Le plus de serveurs que vous avez dans le cluster, les frais généraux supplémentaires impliqués.
Tomcat aide avec cette surcharge en définissant deux modes pour la réplication de session.
DeltaManager (par défaut) et BackupManager
A partir de cette URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
En utilisant la configuration ci-dessus permettre à tous à toute réplication de session en utilisant la DeltaManager pour reproduire deltas session. On entend par que la session est répliquée vers tous les autres nœuds du cluster. Cela fonctionne très bien pour les petites grappes mais nous ne le recommandons pas pour les grandes grappes (beaucoup de nœuds tomcat). En outre lors de l'utilisation du gestionnaire delta, il répliquer à tous les nœuds, même les nœuds qui n'ont pas l'application déployé. Pour contourner ce problème, vous devez utiliser BackupManager. Ce gestionnaire réplique uniquement les données de session sur un noeud de sauvegarde et uniquement sur les noeuds sur lesquels l'application a été déployée. Le seul inconvénient du BackupManager: pas tout à fait que la bataille testé en tant que gestionnaire delta
Lire this URL pour obtenir des conseils de bonne conception du cluster si la réplication permettant de session.
mémoire
Combien d'utilisateurs simultanés seront frappais l'application? Plus il y a d'utilisateurs, plus les données sont stockées dans les sessions, et donc une surcharge pour la réplication de session.
considérations Code
De plus, vous devez assurer que les données mises à la session par l'application est sérialisable. Les données de session de sérialisation ont une certaine surcharge pour la réplication de l'état de la session. C'est une bonne idée de garder la taille de la session raisonnablement petite, donc les développeurs ont besoin de vérifier la quantité de données mises dans la session.
Sessions Post-it
Compte tenu de ces considérations, il dépend en fait de la criticité des cas d'utilisation. Si vous optez pour des sessions collantes seules, il existe un risque de perte de données utilisateur lors d'un voyage critique.
Avez-vous des moyens de récupérer de cela - par exemple: en conservant les données critiques dans la base de données à chaque étape d'une commande ou d'un voyage de paiement? Si ce n'est pas le cas, l'utilisateur doit se connecter et recommencer. Ceci est bien pour les sites qui ne sont pas transactionnels, mais naviguez sur le type de données de brochure ou de remplir des formulaires pour capturer des données qui ne sont pas de paiement, etc
Je préfère Sticky session avec memcache.
Faites-vous référence à la 'réplication de session' sur plusieurs serveurs Tomcat en cluster afin que la session puisse basculer? – JoseK
Oui! Je me demande ce qui est mieux, la réplication de session ou la session de bâton et leurs inconvénients. –