Maison > Article > développement back-end > Parlons de quatre solutions pour le partage de session PHP
Cet article vous présentera les connaissances liées à la session PHP. Commençons par pourquoi ce type de solution de partage de session se produit. J'espère que cela sera utile aux amis qui en ont besoin ~
Comprenez d'abord pourquoi ce type de partage de session se produit. .La solution ?
Les projets des sociétés Internet étant construits dans des microservices et des environnements distribués, un projet peut être déployé dans plusieurs voire plusieurs clusters de serveurs. A ce moment, un problème va se poser :
Lorsque l'utilisateur mène une session, par exemple. , lorsqu'un utilisateur se connecte à un projet, la plupart des projets des grandes entreprises utilisent Nginx pour le reverse proxy.
Voici une brève liste de plusieurs stratégies de proxy inverse couramment utilisées par Nginx :
Stratégie de sondage, stratégie de ratio de poids, ip_hash. stratégie et stratégies personnalisables.
Sous le proxy inverse de Nginx, les requêtes des utilisateurs sont généralement distribuées sur différents serveurs, mais si la requête de l'utilisateur est stockée dans La requête est sur le serveur A, alors l'ID de session de l'utilisateur est stocké dans un ConcurrentHashmap de la JVM. sur le serveur, avec l'ID de session comme clé.
Mais si un module de service demandé par l'utilisateur à ce moment doit être appelé sur le serveur B, lorsque l'utilisateur initie la demande, l'ID de session de l'utilisateur n'est pas stocké sur le serveur B à ce moment, il sera donc demandé à l'utilisateur pour effectuer à nouveau une opération de connexion. Cela peut également conduire à une situation dans laquelle l'utilisateur souhaitait initialement terminer une opération de commande, mais s'est connecté plusieurs fois.
La solution de partage de session est donc particulièrement importante dans les environnements distribués et les systèmes de microservices. [Apprentissage recommandé : "Tutoriel vidéo PHP"]
En fait, il s'agit de prendre un module du nombre de serveurs disponibles dont vous disposez en fonction de l'adresse IP demandée, et alors ce sera votre demande qui sera distribuée au serveur correspondant via le proxy inverse de Nginx. (Les serveurs disponibles seront ici mis dans un tableau. Si le résultat obtenu en prenant le modulo est 0, la requête sera affectée au serveur avec l'indice 0 dans le tableau des serveurs)
Mise en œuvre spécifique :
Vous devez être dans Nginx Apportez les modifications correspondantes dans le fichier .conf en fonction de votre propre serveur disponible
upstream backend{ ip_hash; server 192.168.128.1:8080 ; server 192.168.128.2:8080 ; server 192.168.128.3:8080 down; server 192.168.128.4:8080 down; } server { listen 8081; server_name test.csdn.net; root /home/system/test.csdn.net/test; location ^~ /Upload/upload { proxy_pass http://backend; } }
Les avantages et inconvénients de cette implémentation :
Cette solution est en fait lorsque l'utilisateur requêtes, copiez l'ID de session généré sur tous les serveurs du système, afin de garantir que lorsque l'utilisateur demande, le serveur A peut appeler le module sur le serveur B et que le service B a également l'ID de session de l'utilisateur, de sorte que l'utilisateur ne sera pas invité pour vous reconnecter. Cela résout le problème.
Comment implémenter la réplication de session dans un code spécifique ?
Avantages et inconvénients de l'utilisation de la réplication de session :
Cette solution consiste en fait à donner l'ID de session généré à chaque demande de l'utilisateur. Mettez-le le serveur Redis. Définissez ensuite un mécanisme de délai d'expiration basé sur les caractéristiques de Redis, afin de garantir que les utilisateurs n'ont pas besoin de se reconnecter pendant le délai d'expiration de la session dans Redis que nous avons défini.
Comment implémenter le code :
Avantages et inconvénients de l'utilisation de Redis pour implémenter le partage de session :
En fait, vous pouvez également mettre la session dans le cookie, car chaque fois que l'utilisateur fera une demande, il placera son propre cookie dans la demande, ce qui garantit qu'à chaque fois que l'utilisateur demande, l'utilisateur ne se connectera pas deux fois dans un environnement distribué.
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!