1. Qu’est-ce que l’équilibrage de charge
Un nouveau site web ne devrait pas être équilibré en charge, car le volume de trafic n’est pas important, donc il n’est pas nécessaire de s’engager dans ces situations. Cependant, avec la croissance rapide du trafic et du trafic des sites web, un seul serveur est limité par ses propres conditions matérielles, et il est difficile de supporter un nombre aussi élevé de visites. Dans ce cas, il y a deux options parmi lesquelles choisir :
1. Mettre à jour le matériel d’un seul serveur, du double cœur au quadricœur, augmenter la mémoire, etc.
2. Augmenter le nombre de serveurs pour partager la charge des serveurs. Atteindre l’objectif d’augmenter la bande passante réseau et la puissance de traitement du serveur.
La première méthode peut être comprise comme le développement vertical, qui est toujours limité. La seconde méthode est le bon choix pour résoudre le problème
Les méthodes d’équilibrage de charge peuvent être divisées en deux directions : l’une consiste à utiliser un logiciel pour obtenir l’équilibrage de charge, et l’autre à mettre en œuvre l’équilibrage de charge matériel (y compris la combinaison du matériel et des logiciels)
Utilisez un logiciel pour obtenir l’équilibrage de charge, et le processus d’équilibrage consomme également certaines ressources système et augmente le temps de réponse. Par exemple, LVS, nginx, haproxy, apache, etc., ces logiciels d’équilibrage de charge basés sur des applications conviennent aux sites web qui ne reçoivent pas un nombre particulièrement élevé de visites. Si vous avez un site web avec un grand nombre de visites comme Sina et 163, utiliser du matériel pour mettre en place l’équilibrage de charge est le choix le plus évident.
Il existe de nombreux algorithmes d’équilibrage de charge, y compris l’équilibrage de charge basé sur le nombre de requêtes, les adresses IP racines et les algorithmes basés sur le trafic. Il y a deux algorithmes que j’utilise souvent.
L’un est basé sur le nombre de requêtes
A, il peut réaliser que chaque serveur peut partager équitablement la requête du client, et si l’un des serveurs tombe en panne, cela ne causera pas d’impact négatif.
b. L’état entre les serveurs doit être synchronisé, comme la session, et d’autres moyens sont nécessaires pour synchroniser ces états.
L’un est selon la propriété intellectuelle
A, ip_hash algorithme peut associer une IP à un serveur, ce qui peut résoudre le problème de synchronisation de session
b. Le problème avec ip_hash c’est que si l’un des serveurs tombe, les utilisateurs mappés à ce serveur seront déprimés.
C, ip_hash peut facilement entraîner un déséquilibre de charge, maintenant le gouvernement du crabe de rivière filtre les mots-clés de recherche de Google, vous constaterez souvent que Google ne peut pas ouvrir, mais cela ira bien au bout d’un moment. Cela a déprimé ces passionnés de Google, et de nombreux utilisateurs sont partis à l’étranger pour trouver des agents. Si cela se produit, ces proxies seront assignés au même serveur, ce qui entraînera une charge déséquilibrée et même des défaillances.
Deuxièmement, qu’est-ce que la tenue de session et quelle est sa fonction
Le maintien de session fait référence à un mécanisme sur l’équilibreur de charge qui garantit que les requêtes d’accès associées au même utilisateur sont distribuées au même serveur lors de l’équilibrage de charge.
À quoi sert le maintien de session, donnez un exemple
Si une demande d’accès utilisateur est assignée au serveur A et se connecte au serveur A, et qu’en peu de temps, cet utilisateur envoie une autre requête, s’il n’y a pas de fonction de suspension de session, la requête de cet utilisateur sera probablement attribuée au serveur B, à ce moment-là il n’y a pas de connexion sur le serveur B, donc il faut se reconnecter, mais l’utilisateur ne sait pas où sa requête est assignée, l’utilisateur a le sentiment d’être connecté, pourquoi doit-il se reconnecter ? L’expérience utilisateur est très mauvaise.
Et si vous achetez quelque chose sur Taobao, depuis la connexion = « Shoot something= » add address = « to pay », il s’agit d’une série de processus, qui peut aussi être comprise comme un processus opérationnel, toute cette série de processus opérationnels doit être réalisée par un seul serveur, et ne peut pas être attribuée à différents serveurs par le load balancer.
La suspension de session a une limite de temps (sauf pour les serveurs qui sont mappés à un temps fixe, comme ip_hash), et divers outils d’équilibrage de charge proposent ce réglage de temps de séance, LVS, apache, etc. Même le langage PHP offre un session.gc_maxlifetime de définir le temps de conservation de la session
Le temps de maintien de la session devrait être fixé plus que le temps de survie de la session, ce qui peut réduire le besoin de synchroniser les séances, mais il ne peut pas être supprimé. Donc la synchronisation des séances doit encore être faite.
Troisièmement, la synchronisation des sessions
Pourquoi la synchronisation des sessions, cela a été mentionné en parlant de tenue de session. Pour plus d’informations, voir Trois méthodes de synchronisation de session dans un cluster Web
Il existe trois méthodes de synchronisation de session dans un cluster web
Après avoir fait un cluster web, vous considérerez d’abord la synchronisation des sessions, car après l’équilibrage de charge, le même accès IP à la même page sera attribué à différents serveurs. Cet article propose donc trois façons différentes de résoudre ce problème selon cette situation :
Tout d’abord, utilisez la base de données pour synchroniser la session
Je n’ai pas utilisé cette méthode lors de la synchronisation multi-serveurs de session, mais si je devais l’utiliser, j’ai pensé à deux méthodes :
1. Utiliser un ordinateur bas de gamme pour construire une base de données afin de stocker la session du serveur web, ou construire cette base de données spéciale sur le serveur de fichiers, lorsque l’utilisateur accède au serveur web, il se rendra dans cette base de données spéciale pour vérifier la situation de la session afin d’atteindre l’objectif de la synchronisation de la session.
2. Cette méthode consiste à mettre la table où la session est stockée avec d’autres tables de base de données ; si mysql est également regroupé, chaque nœud mysql doit avoir cette table, et la table de données de cette table de session doit être synchronisée en temps réel.
Explication : Utiliser la base de données pour synchroniser les sessions augmentera la charge sur la base de données, qui est intrinsèquement sujette à des goulets d’étranglement. La première des deux méthodes ci-dessus est meilleure, qui sépare indépendamment la table où la session est placée, réduisant ainsi la charge sur la base de données réelle
2. Utiliser des cookies pour synchroniser les sessions
La session concerne la situation des fichiers stockée côté serveur, et le cookie est la situation des fichiers sur le client, comment obtenir la synchronisation ? La méthode est très simple, c’est-à-dire qu’il s’agit de mettre la session générée par la page visite de l’utilisateur dans le cookie, c’est-à-dire d’utiliser le cookie comme station relais. Vous visitez le serveur web A, générez une session et la mettez dans le cookie, votre accès est attribué au serveur web B, à ce moment-là, le serveur web B juge d’abord si le serveur a cette session, sinon, allez voir s’il y a cette session dans le cookie du client, sinon, cela signifie que la session n’est pas vraiment sauvegardée, s’il y en a une dans le cookie, Synchronisez le sessoin du cookie avec le serveur web B, afin que la session puisse être synchronisée.
Note : Cette méthode est simple et pratique à mettre en œuvre, et n’augmentera pas la charge sur la base de données, mais si le client désactive les cookies, la session ne peut pas être synchronisée, ce qui entraînera des pertes sur le site web ; Les cookies ne sont pas très sécurisés, et bien qu’ils aient été chiffrés, ils peuvent toujours être falsifiés.
3. Utiliser memcache pour synchroniser les sessions
Memcache peut être distribué, et sans cette fonction, il ne peut pas être utilisé pour la synchronisation des sessions. Il peut combiner la mémoire du serveur web pour former un « mempool », quel que soit le serveur qui génère sessoin, il peut être placé dans ce « mempool », et tout le reste peut être utilisé.
Avantages : synchroniser les sessions de cette manière n’augmente pas la charge sur la base de données, et la sécurité est grandement améliorée par rapport à l’utilisation de cookies, et mettre les sessions en mémoire est bien plus rapide que de lire des fichiers.
Inconvénients : memcache divise la mémoire en plusieurs spécifications de blocs de stockage, il y a des blocs et des tailles, ce qui détermine aussi que memcache ne peut pas utiliser pleinement la mémoire, cela entraînera une fragmentation de mémoire ; si le bloc de stockage est insuffisant, cela produira aussi un débordement de mémoire.
Quatrièmement, résumé
Les trois méthodes ci-dessus sont réalisables
La première méthode, celle qui affecte le plus la vitesse du système, n’est pas recommandée ;
La seconde méthode donne de bons résultats, mais les risques pour la sécurité restent les mêmes ;
La troisième méthode, je pense personnellement que la troisième est la meilleure, je recommande à tout le monde de l’utiliser ;
|
Publié sur 14/05/2015 00:16:44
|
|
|
