Prise en charge des sessions Java multi-sites
NCache fournit une persistance de session multisite qui peut être utilisée pour gérer des sessions Java de servlet sur plusieurs batteries de serveurs Web (géographiquement séparées) si vous ne souhaitez pas répliquer des sessions sur le WAN en raison des coûts de consommation de bande passante.
Pour comprendre la persistance des sessions multisites, considérez les applications de servlet Java qui s'exécutent dans des batteries de serveurs Web à charge équilibrée qui s'étendent sur plusieurs régions. Un Load Balancer peut rediriger les clients vers différentes régions en fonction du trafic utilisateur. Pour mettre en cache les sessions Java, un cache en cluster est requis afin que les sessions se répliquent dans toutes les régions. Cette approche peut ne pas convenir en raison de la réplication de session sur le WAN. En outre, cela peut poser des problèmes de performances car les nœuds de mise en cache sont géographiquement séparés.
NCache Sessions Java multi-sites
Pour résoudre ces problèmes, NCache présente le concept de sessions multi-sites. La mise en cache des sessions dans une application de fermes de serveurs Web géographiquement séparées nécessite la configuration de caches distincts dans chaque région. Supposons que vous disposiez de quatre régions, chacune configurée avec des caches distincts comme CR-1, CR-2, CR-3 et CR-4. Chaque cache cluster possède son propre ensemble de clients (servlet Java) en tant que batterie de serveurs Web. Chaque client configurera le NCache filtre de servlet de session. Vous devez spécifier le cache principal (cache de la région actuelle) et un ensemble de caches secondaires (liste des autres caches de région) ainsi que les préfixes définis par l'utilisateur pour chaque nom de cache.
Cette configuration se charge lors de l'initialisation du NCache filtre du fournisseur de session. De cette façon, chaque client aura connaissance des caches dans d’autres régions. L'ID de session créé par le NCache Le fournisseur de session est conforme au préfixe du cache principal de chaque région, c'est-à-dire que le préfixe du cache principal est ajouté aux ID de session de cette région. Ces clients ajouteront, mettront à jour et obtiendront des sessions principalement à partir de leur propre cache cluster, c'est-à-dire le cache principal. Cependant, il arrive parfois qu'une demande client soit envoyée à la batterie de serveurs Web d'un autre emplacement géographique pour l'équilibrage de charge. Maintenant, NCache identifiera la requête à partir de son préfixe de cache principal et permettra aux requêtes de l'utilisateur d'accéder à la même session à partir du cache précédent.
Pour comprendre cela, considérons un itinéraire de requête vers une batterie de serveurs Web du cache de la région CR-2. Dans cette situation, NCache extrait le préfixe de l'ID de session qui sera CR-1 et recherchera son ID de cache dans sa propre liste de caches secondaires. Comme tous les clients de la région disposeront d'un ensemble de caches de toutes les autres régions comme caches secondaires, NCache récupérera cette session du cache CR-1. NCache mettra à jour l'ID de cette session en ajoutant son préfixe de cache principal actuel, c'est-à-dire CR-2, et en le mettant à jour dans le cache principal actuel (CR-2) pour répondre aux demandes futures.
Supposons qu'un client fasse une requête qui passe par l'équilibreur de charge. Supposons que la demande de session soit transmise au serveur Web1 au sein d'une batterie de serveurs Web en fonction de la charge du système. Une fois la demande arrivée, une session est créée avec le préfixe Web Server1 ajouté à l'ID de session et enregistrée dans le cache principal de cette batterie de serveurs Web, dans ce cas, le cache répliqué1.
Lorsque l'équilibreur de charge achemine le même client vers Web Farm2, NCache analyse le préfixe de session. À l'aide de ce préfixe, il récupère la session de Replicated Cache1 même si elle appartient à Web Farm1. Cela vous permet d'avoir deux centres de données actifs ou plus et de conserver la majeure partie du trafic dans son propre centre de données, mais de le déborder occasionnellement vers d'autres centres de données si nécessaire. Vous pouvez également arrêter l'un des centres de données sans provoquer d'interruption pour les utilisateurs car leurs sessions seront accessibles par d'autres centres de données. Ou nous pouvons dire que si l'une des batteries de serveurs Web tombe en panne pour une raison quelconque, d'autres batteries de serveurs Web commenceront à accéder aux sessions utilisateur à partir du cache de cette région et, finalement, toutes les données de session seront déplacées vers le cache de la région suivante pour éviter de perdre la session. données.
NCache fournit une option de modification sans code pour les applications Web basées sur Java afin de stocker les sessions dans NCache en implémentant le module de session nc-sessionprovider.jar en tant que filtre de servlet JSP. Pour utiliser le NCache Module de session Java, vous devez exécuter un conteneur compatible Servlet 2.3+ (serveur Web). L'utilisateur n'a qu'à référencer quelques bibliothèques et ajouter un filtre dans le web.xml de l'application afin que toutes les demandes parviennent à l'application via NCache. Les plates-formes J2EE/Jakarta suivantes sont prises en charge :
- Matou
- JBoss/WildFly
- Logique Web
- WebSphere
Pour en savoir plus sur la façon dont vous pouvez configurer le module de session multisite, veuillez vous référer à Fournisseur d'état de session multisite.
Voir aussi
Aperçu conceptuel
Configuration des applications pour utiliser le module de session Java
Journalisation des erreurs