partage de l'algorithme d'équilibrage de charge nignx-tutoriel mysql-php.cn

Cet article partage principalement avec vous l'algorithme d'équilibrage de charge nignx, dans l'espoir d'aider tout le monde.

1. Algorithme d'équilibrage de charge Nginx

1. Interrogation (par défaut)

Chaque requête est attribuée à un service backend différent une par une dans l'ordre chronologique. Si un serveur tombe en panne, le système défectueux sera automatiquement éliminé afin que l'accès des utilisateurs ne soit pas affecté.

2. Poids (poids d'interrogation)

Plus la valeur du poids est grande, plus la probabilité d'accès qui lui est attribuée est élevée. Il est principalement utilisé lorsque les performances de chaque serveur dans le backend sont déséquilibrées. . Ou définissez simplement des poids différents dans la situation maître-esclave pour obtenir une utilisation raisonnable et efficace des ressources de l'hôte.

3. Méthode de hachage de l'adresse source ip_hash

L'idée du hachage de l'adresse source est d'obtenir une valeur calculée via une fonction de hachage basée sur l'adresse IP du client, et d'utiliser cette valeur pour comparer la liste des serveurs Effectuez une opération modulo sur la taille, et le résultat est le numéro de série auquel le client souhaite accéder au serveur. La méthode de hachage de l'adresse source est utilisée pour l'équilibrage de charge. Les clients avec la même adresse IP seront mappés sur le même serveur back-end pour y accéder à chaque fois que la liste des serveurs back-end reste inchangée.

4. fair

Un algorithme d'équilibrage de charge plus intelligent que Weight et ip_hash, l'algorithme fair peut effectuer intelligemment un équilibrage de charge en fonction de la taille de la page et du temps de chargement, c'est-à-dire en fonction de la réponse de le temps du serveur back-end est alloué aux requêtes, et celles avec des temps de réponse courts sont allouées en premier. Nginx lui-même ne prend pas en charge fair. Si vous avez besoin de cet algorithme de planification, vous devez installer le module amont_fair.

5. url_hash

Alloue les requêtes en fonction du résultat de hachage de l'URL consultée, de sorte que chaque URL soit dirigée vers un serveur back-end, ce qui peut encore améliorer l'efficacité du back-end serveur de cache final. Nginx lui-même ne prend pas en charge url_hash. Si vous avez besoin de cet algorithme de planification, vous devez installer le package logiciel de hachage Nginx.

1. Sondage (par défaut)

Chaque requête est attribuée à un serveur backend différent une par une par ordre chronologique. Si le serveur backend tombe en panne, il peut être automatiquement éliminé.

2. Poids

spécifie la probabilité d'interrogation. Le poids est proportionnel au taux d'accès et est utilisé lorsque les performances du serveur back-end sont inégales.
Par exemple :

upstream bakend {  
server 192.168.0.14 weight=10;  
server 192.168.0.15 weight=10;  
}

Copier après la connexion

3. ip_hash

Chaque requête est allouée en fonction du résultat de hachage de l'IP accédée, afin que chaque visiteur ait un accès fixe à un back-end. serveur, ce qui peut résoudre le problème de session.
Par exemple :

upstream bakend {  
ip_hash;  
server 192.168.0.14:88;  
server 192.168.0.15:80;  
}

Copier après la connexion

4. Fair (tiers)

Attribuez les requêtes en fonction du temps de réponse du serveur backend, et celles avec des temps de réponse courts seront attribuées en premier. .

upstream backend {  
server server1;  
server server2;  
fair;  
}

Copier après la connexion

5. url_hash (tiers)

Distribuez les requêtes en fonction du résultat de hachage de l'URL consultée, afin que chaque URL soit dirigée vers le même serveur back-end. le serveur back-end est mis en cache Plus efficace.
Exemple : ajoutez une instruction de hachage en amont. D'autres paramètres tels que le poids ne peuvent pas être écrits dans l'instruction du serveur. hash_method est l'algorithme de hachage utilisé

upstream backend {  
server squid1:3128;  // 10.0.0.10:7777
server squid2:3128;  //10.0.0.11:8888
hash $request_uri;  
hash_method crc32; }

Copier après la connexion

2. >

Dans le module amont de Nginx, vous pouvez définir l'état de chaque serveur backend dans la planification de l'équilibrage de charge. Les statuts couramment utilisés sont :

1. down, indiquant que le serveur actuel ne participe pas à l'équilibrage de charge. pour le moment

2. Sauvegarde, machine de sauvegarde réservée. Lorsque toutes les autres machines non de sauvegarde tombent en panne ou sont occupées, la machine de sauvegarde sera demandée, donc la pression d'accès de cette machine est la plus basse

3. max_fails, le nombre d'échecs de requête autorisés, par défaut est 1, lorsqu'il dépasse Lorsque le nombre maximum de fois est atteint, l'erreur définie par le module proxy_next_upstream est renvoyée.

4. fail_timeout, délai d'expiration de la demande, le délai de suspension du service après les échecs de max_fails. max_fails et fail_timeout peuvent être utilisés ensemble.

Si Nginx ne pouvait pas proxy uniquement un serveur, il ne serait pas aussi populaire qu'aujourd'hui. Nginx peut être configuré pour proxy plusieurs serveurs lorsqu'un serveur tombe en panne, le système peut toujours rester disponible. Le processus de configuration spécifique est le suivant :

1 Sous le nœud http, ajoutez le nœud en amont.

upstream linuxidc { 
      server 10.0.6.108:7080; 
      server 10.0.0.85:8980; 
}

Copier après la connexion

2. 将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称，即“
http://linuxidc”.

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://linuxidc; 
}

Copier après la connexion

3. 现在负载均衡初步完成了。upstream按照轮询（默认）方式进行负载，每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡。适用于图片服务器集群和纯静态页面服务器集群。

除此之外，upstream还有其它的分配策略，分别如下：

weight（权重）

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。如下所示，10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。

upstream linuxidc{ 
      server 10.0.0.77 weight=5; 
      server 10.0.0.88 weight=10; 
}

Copier après la connexion

ip_hash（访问ip）

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream favresin{ 
      ip_hash; 
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
}

Copier après la connexion

fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。与weight分配策略类似。

 upstream favresin{      
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
      fair; 
}

Copier après la connexion

url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

注意：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。

 upstream resinserver{ 
      server 10.0.0.10:7777; 
      server 10.0.0.11:8888; 
      hash $request_uri; 
      hash_method crc32; 
}

Copier après la connexion

upstream还可以为每个设备设置状态值，这些状态值的含义分别如下：

down 表示单前的server暂时不参与负载.

weight 默认为1.weight越大，负载的权重就越大。

max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后，暂停的时间。

backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态

  ip_hash; 
      server 10.0.0.11:9090 down; 
      server 10.0.0.11:8080 weight=2; 
      server 10.0.0.11:6060; 
      server 10.0.0.11:7070 backup; 
}

Copier après la connexion