Exigences : Utilisez Nginx pour construire un proxy inverse, responsable de la planification de toutes les requêtes, le backend est développé par ASP.NET MVC et déployé sur plusieurs serveurs différents, formant un cluster backendLes informations de session ne peuvent pas être partagées, ce qui entraîne un traitement incorrect de certaines requêtes。 Les problèmes suivants vont surgir :
ASP.NET Le site web peut être désigné comme suit :
Les solutions couramment utilisées sont les suivantes :
Utilisez la base de données pour stocker la SESSION
Puisque chaque serveur doit utiliser la même session, nous pouvons stocker la session dans la même base de données, à chaque accès, nous allons dans la base de données pour vérifier s’il existe cette session ou si elle est expirée, puis nous pouvons synchroniser la session de plusieurs serveurs ;
Mérite:Utiliser cette méthode est simple, pratique et facile à démarrer ;
Défaut:Utiliser la base de données pour synchroniser les sessions augmentera l’IO de la base de données et augmentera la charge sur celle-ci. En même temps, chaque accès doit intercepter les requêtes et interroger la base de données, ce qui entraîne une couche supplémentaire d’accès et une perte de temps de session de base de données.
Utilisez un mécanisme de mise en cache tel que Memcache ou Redis pour stocker la SESSION
L’utilisation de mécanismes de mise en cache distribuée tels que memcache ou redis pour stocker les données de session est une solution populaire pour l’équilibrage de charge et les sessions synchrones dans de nombreux projets à grande échelle. Son principe est que le projet utilise le cache memcache ou le cache redis au même endroit, lorsque l’utilisateur se connecte, la session sera stockée dans le cache, et quel que soit le serveur du projet accédé, le cache de session sera obtenu au même endroit, permettant ainsi la synchronisation de la session de se réaliser facilement ;
Mérite:Utiliser le cache pour synchroniser les sessions n’augmentera pas la charge sur la base de données, ni n’aura besoin de juger manuellement si la session existe ou expire, éliminant ainsi une partie de la logique métier.
Défaut:Memcache ou Redis divise la mémoire en plusieurs spécifications de blocs de stockage, et il existe des blocs de taille, ce qui détermine également que Memcache ou Redis ne peuvent pas utiliser pleinement la mémoire, ce qui entraînerait une fragmentation de la mémoire, et si les blocs de stockage sont insuffisants, un débordement de mémoire surviendra également.
Exploitez le motif ip_hash dans Nginx
Cette technique, également appelée tenue de session, est la ip_hash technologie dans nginx qui vous permet deLes requêtes provenant d’une certaine adresse IP sont épinglées sur le même serveur d’applications backend, afin qu’un client et un backend sous cette IP puissent établir une session stable.
(Mais il y a aussi un inconvénient, si le réseau de l’opérateur est plus volatil et instable,L’IP de sortie est dynamiqueOui, il y aura des problèmes avec cette méthode. )
La méthode de test consiste à ouvrir deux sites basés sur Docker,Vous devez créer un nouveau fichier index.html sous les annuaires /data/testsite/a et /data/testsite/b, respectivement, la commande est la suivante :
Accès via un navigateur comme indiqué ci-dessous :
Si vous créez un nouveau conteneur nginx basé sur Docker, sans utiliser ip_hash technologie, la requête peut être envoyée à différents serveurs backend, comme montré dans la figure ci-dessous :
En utilisant ip_hash technologie, créez un nouveau fichier /data/testsite/nginx.conf avec la configuration suivante :
La commande de démarrage Docker est la suivante :
(La tenue de session basée sur les cookies, qui peut être consultée dans le module épinglé, a été omis)
Configuration Nginx :La connexion hyperlientérée est visible.
(Fin)
|