Problèmes de partage de session intégré

2.1 Sauvegarde des cookies client

Introduction

est enregistrée côté client de manière cryptée par cookie L'avantage est de réduire la pression côté serveur à chaque fois. écrit côté client, puis soumettez-le à nouveau au serveur via le navigateur. Même si deux requêtes sont complétées sur deux serveurs du cluster, le partage de session peut être atteint.

L'avantage de cette solution est que les informations de session n'ont pas besoin d'être stockées côté serveur, ce qui réduit considérablement la pression sur le serveur. Un autre avantage est que deux requêtes ou plus dans une session peuvent être exécutées sur plusieurs serveurs d'un cluster, évitant ainsi les points de défaillance uniques. Actuellement, Taobao adopte cette solution.

Il y a plusieurs inconvénients. Premièrement, lors du passage des cookies, la limite de longueur de l'en-tête http nous permet de stocker uniquement une partie des informations de l'utilisateur dans le cookie. Deuxièmement, un travail supplémentaire est nécessaire pour crypter les informations de session ; , si cette méthode est adoptée, chaque fois que vous accédez au nom de domaine de deuxième niveau du site Web, les informations de session stockées sous forme de cookies seront incluses dans l'en-tête d'information http, qui occupera finalement une certaine quantité de bande passante ; parce que cette méthode consiste à traiter les informations sur le stockage du client, les utilisateurs peuvent désactiver complètement les cookies ou supprimer les cookies, ce qui n'est pas très fiable.

2.2 Synchronisation de session entre serveurs

Introduction

Utilisation de l'architecture de serveur maître-esclave, lorsque l'utilisateur se connecte sur le serveur maître, via un script ou un processus démon, Pass les informations de session à chaque serveur esclave, de sorte que lorsque l'utilisateur accède à d'autres serveurs esclaves, les informations de session puissent être lues.

Inconvénients : tels que la lenteur, l'instabilité, etc. De plus, si la transmission des informations de session est unidirectionnelle maître->esclave, il y aura certains risques. Par exemple, si le serveur principal est en panne, les autres serveurs ne pourront pas obtenir d'informations de session

2.3 Utiliser un cluster pour gérer les sessions de manière uniforme

Introduction

Fournir un cluster pour enregistrer les informations partagées de la session. leurs informations de session dans le groupe de serveurs de cluster de session. Lorsque le système d'application a besoin d'informations de session, il les lit directement à partir du serveur de cluster de session. À l'heure actuelle, la plupart d'entre eux utilisent Memcache pour stocker les sessions.

Il existe actuellement deux solutions d'implémentation populaires pour utiliser Memcache pour implémenter le partage de session. Ces deux solutions sont principalement présentées ci-dessous.

2.3.1 Utiliser la méthode Filter

Cette méthode utilise la méthode filter pour reconditionner l'objet httpRequest et ajoute le client memcached Les avantages de cette méthode sont : elle est simple à utiliser et filtre. Configurez-le simplement sur le serveur. De plus, il est plus flexible car il est implémenté sur le client, la configuration est plus flexible et il est indépendant du serveur. Vous pouvez le déployer sur n'importe quel conteneur prenant en charge les servlets.

2.3.2 memcached-session-manager (MSM)

memcached-session-manager, communément appelé MSM, est une solution open source utilisée pour résoudre le problème du partage de session dans un système distribué. environnement Tomcat. Son principe d'implémentation est de le déployer sur le serveur en tant que plug-in Tomcat, de modifier le code lié à la session dans le code du conteneur du servlet, de le connecter à memcached, et de créer et mettre à jour la session dans memcached. MSM possède les fonctionnalités suivantes :

Prend en charge Tomcat6, Tomcat7

Prend en charge les sessions persistantes et non persistantes

Aucun point de défaillance unique

Peut gérer le basculement de Tomcat

Peut gérer le basculement Memcached

Sérialisation de session de plug-in

Permet d'enregistrer la session de manière asynchrone pour améliorer la vitesse de réponse

Uniquement lorsque la session est modifiée, Ce n'est qu'alors que la session sera réécrite dans memcached

JMX Management & Monitoring

MSM (memcached-session-manager) prend en charge Tomcat6 et Tomcat7 et utilise Value (valve Tomcat) pour suivre la demande. Lorsque la requête Request arrive, la session est chargée à partir de Memcached. Lorsque la requête Request se termine, la session Tomcat est mise à jour vers Memcached pour atteindre l'objectif de partage de session.

Avantages : les développeurs n'ont plus besoin d'envisager le partage de session. Ils peuvent se concentrer sur le développement du programme et simplement l'utiliser comme une session normale. Il n'est pas nécessaire d'écrire du code explicitement, il vous suffit de configurer le serveur pour l'utiliser.

Inconvénients : Si vous souhaitez modifier la politique de session, vous devez redéployer le conteneur de servlet de chaque serveur.

Pour plus de détails, veuillez vous référer à : http://code.google.com/p/memcached-session-manager/

2.4 Session persistante dans la base de données

Introduction

Cette méthode de partage de session stocke les informations de session dans la base de données, et d'autres applications peuvent vérifier les informations de session à partir de la base de données. La base de données actuellement utilisée lors de l'utilisation de cette solution est généralement mysql.

La solution consistant à utiliser la base de données pour partager la session présente une certaine praticité, mais elle présente également les inconvénients suivants : Premièrement, la lecture et l'écriture simultanées de la session sont effectuées dans la base de données, ce qui nécessite des performances relativement élevées de MySQL ; deuxièmement, nous devons en outre implémenter la session Éliminer le code logique, c'est-à-dire mettre à jour et supprimer régulièrement les informations de session de la table de la base de données, ce qui augmente la charge de travail

2.5 Configurez le serveur d'équilibrage de charge pour permettre à la session d'un utilisateur de se terminer sur un serveur. Sauvegardez régulièrement les informations de session sur le serveur après une panne, la demande de l'utilisateur est transmise de manière transparente aux autres serveurs du cluster via le serveur d'équilibrage. cette fois, les informations de session sauvegardées doivent être lues à partir du baume.

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!