Comment configurer l'équilibrage de charge nginx

Polling

nginx distribue toutes les requêtes uniformément à chaque serveur du cluster.

upstream test {
server 127.0.0.1:7001; # 等同于server 127.0.0.1:7001 weight=1;server 150.109.118.85:7001; # 等同于server 150.109.118.85:7001 weight=1;}

server {
listen 8081;
server_name localhost;

location / {
 proxy_pass http://test/;
}
}

upstream : Définissez un cluster de services. proxy_pass : transférez le proxy de requête correspondant au service configuré derrière proxy_pass. L'équilibrage de charge devant être configuré ici, http:// doit être suivi du cluster de services défini en amont. http://后面必须要跟上upstream定义的服务集群。

注意：upstream定义服务集群时，配置的服务地址只能是域名+端口或者ip+端口，不能带有协议和路径，否则nginx会报nginx: [emerg] invalid host in upstream这个错误信息。

加权（weight）

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

前面两次请求都会转发到127.0.0.1:7001这个服务，后面一次请求会转发到150.109.118.85:7001这个服务，再后面两次转发到127.0.0.1:7001，。。。

最少连接数

文件位置：src/http/modules/ngx_http_upstream_least_conn_module.c

nginx请求分配给active_connection/weight最小的服务器。

upstream test {
  least_conn;
server 127.0.0.1:7001 weight=1;
server 150.109.118.85:7001 weight=1;
}

ip_hash

文件位置：src/http/modules/ngx_http_upstream_ip_hash_module.c

根据用户的ip，计算出一个hash值，如果负载均衡缓存中有这个hash对应的服务器，那就直接转发到对应的服务器上。

upstream test {
  ip_hash;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

nginx使用ip_hash策略后，只要用户电脑的ip不变化，就会始终请求同一台业务服务。

应用场景：在实现文件上传功能时，要实现一个大文件上传，往往会将这个大文件分成多个片段，然后上传到服务器，如果使用前面给的策略，就会出现同一个文件的分片被上传到不同服务器，导致文件合并失败，不能达到预期效果。nginx使用ip_hash策略后，客户端只要上传了当前文件的一个片段，后续文件片段上传的时候，nginx通过计算ip的hash，自动把请求转发到hash对应的服务器。

hash

文件位置：src/http/modules/ngx_http_upstream_hash_module.c

可以进行hash计算的有remote_addr（客户端ip）（从测试结果上面看感觉可以直接替换掉ip_hash）、request_uri(请求uri)、args（请求参数），下面主要以request_uri的使用作为展示，其他两个使用都类似。

根据请求的uri计算出一个hash值，然后将该请求转发到一台服务器上面，后续请求通过hash计算后，如果有相同的hash，那么就会将该请求转发到该hash对应的服务器。

假设集群中某台服务器宕机后会发生什么情况：如果r1命中a服务器，r2会命中哪个服务器？。如果a服务器宕机，之前通过r1计算出来的哈希值与a服务器的对应关系会失效，并且r1会重新分发给b服务器。后续a服务器恢复正常后，r1还是会分配给b服务器。

upstream test {
  hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

应用场景：所有请求相同的文件资源的请求都会被转发到同一个服务器，资源更容易命中缓存，减少宽带和资源下载时间。

consistent_hash

consistent_hash（一致性hash）这个模块使用方式和nginx内置的hash模块几乎相同。能够使用consistent_hash进行计算的内容和前面提到的nginx内置的hash模块一样，有remote_addr、request_uri、args。您可以在这里下载 ngx_http_consistent_hash，它是一个用于三方模块的软件。

upstream test {
consistent_hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

fair

响应时间短的服务优先分配请求。您可以在nginx_upstream_fair的下载页面获取该三方模块。这个模块上次更新是8年前，可能需要考虑下是否需要使用这个。

upstream test {
fair;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

测试中得出效果和轮询默认情况效果一样，暂时没有找到问题在哪。。。

负载均衡相关参数

down

标识down的服务器暂时不支持资源请求。

upstream test {
server 127.0.0.1:7001 down;
server 150.109.118.85:7001;
}

上面负载均衡的例子中，因为127.0.0.1:7001标识为down，所以不会有请求转发到这个服务，所有的请求都会转发到150.109.118.85:7001

Remarque : Lorsque l'amont définit un cluster de services, l'adresse de service configurée ne peut être que nom de domaine + port ou ip + port, et ne peut pas contenir de protocole et de chemin, sinon nginx signalera nginx : [emerg] hôte invalide en amont< /code>Ce message d'erreur. </strong></p>Weighted<p><div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="custom">upstream test { server 127.0.0.1:7001 weight=2; server 150.109.118.85:7001 weight=1; }</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div></p>Les deux premières demandes seront transmises au service <code>127.0.0.1:7001, et la demande suivante sera transmise au service 150.109.118.85:7001 service service, puis transmis à 127.0.0.1:7001 deux fois. . .

Nombre minimum de connexions

Emplacement du fichier : src/http/modules/ngx_http_upstream_least_conn_module.c

Les requêtes nginx sont attribuées au serveur avec la plus petite connexion/poids actif.

upstream test {
server 127.0.0.1:7001 max_fail=1;
server 150.109.118.85:7001;
}

ip_hash

Emplacement du fichier : src/http/modules/ngx_http_upstream_ip_hash_module.c🎜🎜Calculez une valeur de hachage basée sur l'adresse IP de l'utilisateur S'il existe un serveur correspondant à ce hachage dans le cache d'équilibrage de charge, ce sera le cas. transmis directement sur le serveur correspondant. 🎜

upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}

🎜Une fois que nginx utilise la politique ip_hash, tant que l'adresse IP de l'ordinateur de l'utilisateur ne change pas, il demandera toujours le même service métier. 🎜🎜Scénario d'application : lors de la mise en œuvre de la fonction de téléchargement de fichiers, pour télécharger un fichier volumineux, le fichier volumineux est souvent divisé en plusieurs fragments puis téléchargé sur le serveur. Si la stratégie indiquée ci-dessus est utilisée, le même fichier sera divisé en fragments. . Les fichiers ont été téléchargés sur différents serveurs, ce qui a entraîné l'échec de la fusion des fichiers et n'a pas permis d'obtenir les résultats escomptés. Une fois que nginx a utilisé la politique ip_hash, le client n'a besoin que de télécharger un fragment du fichier actuel. Lorsque les fragments de fichier suivants sont téléchargés, nginx transmet automatiquement la demande au serveur correspondant au hachage en calculant le hachage de l'IP. 🎜🎜hash🎜🎜Emplacement du fichier : src/http/modules/ngx_http_upstream_hash_module.c🎜🎜Les calculs de hachage qui peuvent être effectués incluent remote_addr (IP du client) (d'après les résultats des tests, il semble que ip_hash puisse être directement remplacé), request_uri ( request uri) , args (paramètres de requête), ce qui suit utilise principalement l'utilisation de request_uri à titre de démonstration, les deux autres utilisations sont similaires. 🎜🎜Calculez une valeur de hachage basée sur l'URI demandé, puis transmettez la demande à un serveur. Une fois les demandes suivantes calculées via le hachage, si elles ont le même hachage, la demande sera transmise au serveur correspondant au hachage. 🎜🎜Supposons que ce qui se passe après la panne d'un serveur du cluster : si r1 atteint le serveur a, quel serveur r2 frappera-t-il ? . Si le serveur a tombe en panne, la correspondance entre la valeur de hachage précédemment calculée par r1 et le serveur a deviendra invalide et r1 sera redistribué au serveur b. Une fois le serveur a revenu à la normale, r1 sera toujours attribué au serveur b. 🎜

upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}

🎜Scénario d'application : toutes les demandes concernant les mêmes ressources de fichiers seront transmises au même serveur, ce qui facilitera l'accès des ressources au cache, réduisant ainsi la bande passante et le temps de téléchargement des ressources. 🎜🎜🎜consistent_hash🎜🎜🎜consistent_hash (hachage cohérent) Ce module est utilisé presque de la même manière que le module de hachage intégré de nginx. Le contenu qui peut être calculé à l'aide de consistent_hash est le même que le module de hachage intégré nginx mentionné précédemment, y compris remote_addr, request_uri et args. Vous pouvez télécharger ici ngx_http_consistent_hash, qui est un logiciel pour modules tiers. 🎜

upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}

🎜fair🎜🎜Les demandes de service avec des délais de réponse courts seront attribuées en premier. Vous pouvez obtenir ce module tiers depuis la page de téléchargement de nginx_upstream_fair. Ce module a été mis à jour pour la dernière fois il y a 8 ans. Vous voudrez peut-être vous demander si vous devez l'utiliser. 🎜

upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}

🎜Dans le test, l'effet est le même que la situation de sondage par défaut, et le problème n'a pas encore été trouvé. . . 🎜🎜Paramètres liés à l'équilibrage de charge🎜🎜🎜down🎜🎜🎜Le serveur marqué down ne prend pas en charge les demandes de ressources temporairement. 🎜rrreee🎜Dans l'exemple d'équilibrage de charge ci-dessus, étant donné que 127.0.0.1:7001 est marqué comme down, aucune demande ne sera transmise à ce service et toutes les demandes seront transmises à 150.109.118.85:7001Ce service. 🎜🎜🎜weight🎜🎜🎜La valeur de poids du service dans le cluster, la valeur par défaut est 1. À condition que seul le poids soit affecté et que tous les services du cluster soient normaux, nginx transmettra davantage de requêtes aux services avec un poids plus important. 🎜rrreee🎜Le ratio de requêtes traitées par le service 127 et le service 150 dans ce cluster est de 2:1. 🎜🎜🎜max_fails🎜🎜🎜Le nombre d'erreurs de service autorisées lorsque le service traite les demandes, la valeur par défaut est 1. Lorsque le nombre d'erreurs dans le traitement des demandes de service dépasse max_fails, les demandes suivantes ne seront pas transmises au service où l'erreur s'est produite. 🎜rrreee🎜🎜fail_timeout🎜🎜

如果某个服务处理请求时发生错误的次数超过 max_fails，nginx 将暂时禁止将请求转发到该服务。当过去fail_timeout设置的时间以后，nginx会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待fail_timeout时间后再来检测。fail_timeout默认时间是10s。

upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}

backup

备用服务器，当所有非backup服务发生错误被停用或者设置为down时，nginx会启用标识为backup的服务。

upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}

max_conns

这个功能存在于nginx商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。

upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}

slow_start

这个功能存在于nginx商业版。当集群中错误服务等待fail_timeout时间后，nginx检测到这个服务能够正常使用后，再等待slow_start时间后，才正式使用这个服务。

upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}

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!