Maison > Article > développement back-end > Comment Nginx effectue-t-il l'équilibrage de charge ? Résumé de l'algorithme d'équilibrage de charge nginx (avec code)

Comment Nginx effectue-t-il l'équilibrage de charge ? Résumé de l'algorithme d'équilibrage de charge nginx (avec code)

不言original: 2018-07-25 16:29:225725parcourir

Comment faire l'équilibrage de charge Nginx ? En fait, il existe de nombreuses façons d'implémenter l'équilibrage de charge Nginx. Je vais maintenant présenter en détail l'algorithme d'équilibrage de charge Nginx, dont cinq algorithmes : polling,weight, ip_hash, fair et url_hash.

1. Algorithme d'équilibrage de charge Nginx

1. Polling (par défaut)

Chaque requête est affectée à un backend différent un par un dans l'ordre chronologique. Service, si un serveur back-end 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. ip_hash

Chaque requête est allouée en fonction du résultat de hachage de l'IP d'accès, afin que les visiteurs de la même IP puissent avoir un accès fixe à un serveur back-end, et puissent effectivement résoudre le problème des pages Web dynamiques.

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 dans l'ordre chronologique. Si le serveur backend tombe en panne, cela peut être le cas. automatiquement éliminé.

2.weight

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;  
}

3.ip_hash

Chaque requête est allouée en fonction du résultat de hachage de l'ip d'accès, afin que chaque le visiteur a un accès fixe. Le serveur back-end peut résoudre les problèmes de session.
Par exemple :

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

4.fair (tiers)

Répartir les requêtes en fonction du temps de réponse du serveur backend, avec une attribution de priorité à temps de réponse court.

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

5.url_hash (tiers)

Distribuer 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 article C'est plus efficace lorsque le serveur back-end est un cache.
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;  
server squid2:3128;  
hash $request_uri;  
hash_method crc32;

2. Nginx. Statut de planification de l'équilibrage de charge

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 le. actuel Le serveur 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; 
}

2. Configurez proxy_pass dans le nœud d'emplacement sous le nœud du serveur comme : http:// + nom en amont, c'est-à-dire "
http://linuxidc".

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

3. L'équilibrage de charge est maintenant initialement terminé. Chargements en amont selon la méthode d'interrogation (par défaut). Chaque requête est attribuée à différents serveurs back-end un par un dans l'ordre chronologique. Si le serveur back-end tombe en panne, il peut être automatiquement éliminé. Bien que cette méthode soit simple et peu coûteuse. Mais les inconvénients sont : une faible fiabilité et une répartition inégale de la charge. Applicable aux clusters de serveurs d'images et aux clusters de serveurs de pages purement statiques.

De plus, l'amont dispose d'autres stratégies d'allocation, comme suit :

Weight (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; 
}

ip_hash（访问ip）

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

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

fair（第三方）

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

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

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; 
}

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; 
}

如果Nginx没有仅仅只能代理一台服务器的话，那它也不可能像今天这么火，Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。具体配置过程如下：

1. 在http节点下，添加upstream节点。

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

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

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

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

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

weight（权重）