Introduction aux méthodes de traitement de session dans un environnement cluster/distribué Linux

Cet article vous présente principalement les cinq stratégies de traitement de session dans un cluster/environnement distribué Linux. L'article les présente en détail à travers des exemples de code et des images. Il a une certaine valeur d'apprentissage de référence pour les études ou le travail de chacun. cela, veuillez suivre l'éditeur pour apprendre ensemble.

Préface

Généralement, après avoir construit un environnement de cluster, un problème que nous devons considérer est de savoir comment gérer les sessions générées par l'accès des utilisateurs. Si aucun traitement n'est effectué, les utilisateurs se connecteront fréquemment. Par exemple, il y a deux serveurs A et B dans le cluster Lorsque l'utilisateur visite le site Web pour la première fois, Nginx transmettra la demande de l'utilisateur au serveur A via son équilibrage de charge. mécanisme. À ce moment, le serveur A créera une session pour l'utilisateur. Lorsque l'utilisateur envoie une requête pour la deuxième fois, Nginx équilibrera la charge de la requête sur le serveur B. À ce stade, le serveur B n'a pas de session, l'utilisateur sera donc renvoyé vers la page de connexion. Cela réduirait considérablement l'expérience utilisateur et entraînerait la perte d'utilisateurs. Cette situation ne devrait jamais se produire dans le projet.

Nous devons traiter la session générée pour garantir l'expérience utilisateur via une session persistante, une copie de session ou un partage de session.

Ci-dessous, j'expliquerai 5 stratégies de traitement de session et analyserai leurs avantages et inconvénients. Pas grand chose à dire, jetons un œil à l’introduction détaillée.

Le premier type : session collante

Principe : Une session collante fait référence au verrouillage de l'utilisateur sur un certain serveur , comme dans l'exemple mentionné ci-dessus, lorsque l'utilisateur demande pour la première fois, l'équilibreur de charge transmet la demande de l'utilisateur au serveur A. Si l'équilibreur de charge définit une session persistante, alors chaque demande ultérieure de l'utilisateur sera transmise au serveur A. , ce qui équivaut à coller l'utilisateur et le serveur A ensemble. C'est le mécanisme de session collante.

Avantages : Simple, pas besoin de faire de traitement sur la session.

Inconvénients : Manque de tolérance aux pannes. Si le serveur actuellement accédé tombe en panne et que l'utilisateur est transféré vers le deuxième serveur, ses informations de session seront invalides.

Scénarios applicables : La panne a un faible impact sur les clients ; la panne du serveur est un événement à faible probabilité.

Méthode d'implémentation : En prenant Nginx comme exemple, une session collante peut être réalisée en configurant l'attribut ip_hash dans le module en amont.

upstream mycluster{
 #这里添加的是上面启动好的两台Tomcat服务器
 ip_hash;#粘性Session
  server 192.168.22.229:8080 weight=1;
  server 192.168.22.230:8080 weight=1;
}

Deuxième type : réplication de session serveur

Principe : Si la session sur un serveur change (ajout, suppression, modification), le nœud sérialisera tout le contenu de la session puis le diffusera à tous les autres nœuds, que d'autres serveurs aient ou non besoin de la session pour assurer la synchronisation de la session.

Avantages : Tolérant aux pannes, les sessions entre serveurs peuvent répondre en temps réel.

Inconvénients : exercera une certaine pression sur la charge du réseau. Si le nombre de sessions est important, cela peut provoquer une congestion du réseau et ralentir les performances du serveur.

Méthode d'implémentation :

① Définissez Tomcat, server.xml pour activer la fonction de cluster Tomcat

Adresse : remplissez Utilisez simplement l'adresse IP locale et définissez le numéro de port pour éviter les conflits de port.

② Ajouter des informations à l'application : notifier que l'application est actuellement dans un environnement de cluster et prend en charge la distribution

Ajouter des options dans web.xml <distributable/>

Troisième type : mécanisme de partage de session

Utilisez des solutions de mise en cache distribuées telles que Memcached et Redis, mais Memcached ou Redis doit être un cluster.

Il existe également deux mécanismes d'utilisation du partage de session. Les deux situations sont les suivantes :

① Méthode de traitement de session collante

Principe : Tomcat différent. accès désigné Différents maîtres memcached. Les informations entre plusieurs Memcached sont synchronisées, permettant une sauvegarde maître-esclave et une haute disponibilité. Lorsqu'un utilisateur accède, il crée d'abord une session dans Tomcat, puis copie la session dans son memcahed correspondant. Memcache ne joue qu'un rôle de sauvegarde, et toutes les lectures et écritures sont effectuées sur Tomcat. Lorsqu'un certain Tomcat raccroche, le cluster localise l'accès de l'utilisateur au Tomcat de secours, puis recherche la session en fonction du SessionId stocké dans le cookie. S'il ne trouve pas la session, il accède au memcached correspondant pour trouver la session. . Après l'avoir trouvé, il le copie sur le Tomcat supérieur de veille.

② Méthode de traitement de session non collante

Principe : memcached effectue la réplication maître-esclave et les écritures dans les sessions sont écrites dans le service memcached esclave, les lectures sont toutes lues à partir du memcached principal, Tomcat lui-même ne stocke pas la session

Avantages : Tolérant aux pannes, la session répond dans temps réel.

Méthode d'implémentation : Utilisez le plug-in msm open source pour résoudre le partage de session entre tomcats : Memcached_Session_Manager (MSM)

a. 复制相关jar包到tomcat/lib 目录下

JAVA memcached客户端：spymemcached.jarmsm项目相关的jar包：1. 核心包，memcached-session-manager-{version}.jar2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。

b. 配置Context.xml ，加入处理Session的Manager

粘性模式配置：

非粘性配置：

 

第四种：session持久化到数据库

原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。

优点：服务器出现问题，session不会丢失

缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

第五种terracotta实现session复制

原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。

优点：这样对网络的压力就非常小，各个节点也不必浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。

实现方式：篇幅原因，下篇再论。

小结

以上讲述的就是集群或分布式环境下，session的5种处理策略。其中就应用广泛性而言，第三种方式，也就是基于第三方缓存框架共享session，应用的最为广泛，无论是效率还是扩展性都很好。而Terracotta作为一个JVM级的开源群集框架，不仅提供HTTP Session复制，它还能做分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调等，也值得学习一下。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!