Nginx の負荷分散を行うにはどうすればよいですか?実際、Nginx の負荷分散を実装するにはさまざまな方法がありますが、ポーリング、ウェイト、ip_hash、fair、url_hash の 5 つのアルゴリズムを含む、Nginx の負荷分散アルゴリズムを詳しく紹介します。
1. Nginx ロード バランシング アルゴリズム
1. ポーリング (デフォルト)
各リクエストは時系列順に 1 つずつ異なるバックエンドに割り当てられます。サービスでは、バックエンドサーバーがクラッシュした場合、障害のあるシステムが自動的に排除されるため、ユーザーのアクセスは影響を受けません。
2. ウェイト(ポーリングウェイト)
ウェイトの値が大きいほどアクセス確率が高く設定され、主にバックエンドの各サーバーのパフォーマンスがアンバランスな場合に使用されます。 。または、マスター/スレーブの状況で異なる重みを設定するだけで、ホスト リソースの合理的かつ効果的な利用を実現できます。
3. ip_hash
各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、同じ IP からの訪問者はバックエンド サーバーに固定的にアクセスでき、効果的にアクセスできます。動的 Web ページの問題、セッション共有の問題を解決します。
4. フェア
ウェイトや ip_hash よりもインテリジェントな負荷分散アルゴリズムである公平アルゴリズムは、ページ サイズと読み込み時間に基づいて、つまり、ページの応答に基づいて負荷分散をインテリジェントに実行できます。バックエンドサーバー リクエストには時間が割り当てられ、応答時間の短いものが最初に割り当てられます。 Nginx 自体は Fair をサポートしていないため、このスケジューリング アルゴリズムが必要な場合は、upstream_fair モジュールをインストールする必要があります。
5. url_hash
アクセスされた URL のハッシュ結果に応じてリクエストを振り分け、各 URL がバックエンド サーバーに振り分けられるようにすることで、バックエンド サーバーの効率をさらに向上させることができます。エンドキャッシュサーバー。 Nginx 自体は url_hash をサポートしていないため、このスケジューリング アルゴリズムが必要な場合は、Nginx ハッシュ ソフトウェア パッケージをインストールする必要があります。
1. ポーリング (デフォルト)
各リクエストは時系列順に 1 つずつ異なるバックエンド サーバーに割り当てられます。 、自動的に削除できます。
2.weight
ポーリング確率を指定します。重みはアクセス率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。
例:
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}3.ip_hash
各リクエストは、アクセスされた IP のハッシュ結果に従って割り当てられるため、各訪問者は1 つのバックエンドにアクセスすると、サーバーはセッションの問題を解決できます。
例:
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}4.fair (サードパーティ)
リクエストは、バックエンド サーバーの応答時間に従って割り当てられ、より短い時間になります。応答時間を優先して配布します。
upstream backend {
server server1;
server server2;
fair;
}5.url_hash (サードパーティ)
アクセスされた URL のハッシュ結果に応じて、各 URL が同じ宛先になるようにリクエストを振り分けます。バックエンド サーバー。バックエンド サーバーがキャッシュされている場合にさらに効果的です。
例: アップストリームにハッシュ ステートメントを追加します。サーバー ステートメントに重みなどの他のパラメーターを記述することはできません。hash_method は使用されるハッシュ アルゴリズムです。
upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;2. Nginx の読み込みスケジューリング ステータスのバランシング
Nginx アップストリーム モジュールでは、ロード バランシング スケジューリングで各バックエンド サーバーのステータスを設定できます。一般的に使用されるステータスは次のとおりです:
1. down (現在の状態を示します)サーバー 当面はロード バランシングに参加しません
2. バックアップ、予約されたバックアップ マシン。他のすべての非バックアップ マシンが失敗するかビジー状態になると、バックアップ マシンが要求されるため、このマシンのアクセス プレッシャーは最も低くなります。
3. max_fails (許可されるリクエスト失敗の数) のデフォルトは 1 です。最大回数に達した場合、proxy_next_upstream モジュールで定義されたエラーが返されます。
4.fail_timeout、要求失敗タイムアウト、max_fails 回の失敗後にサービスを一時停止する時間。 max_fails とfail_timeout は一緒に使用できます。
もし Nginx が 1 つのサーバーのみをプロキシできなかったら、今日ほど人気はなかっただろう。Nginx は複数のサーバーをプロキシするように構成できます。1 つのサーバーがダウンしても、システムは引き続き利用可能です。具体的な構成プロセスは次のとおりです:
1. http ノードの下に、上流ノードを追加します。
upstream linuxidc {
server 10.0.6.108:7080;
server 10.0.0.85:8980;
} 2. サーバー ノードの下のロケーション ノードで proxy_pass を次のように設定します。 http:// アップストリーム名、つまり、「
http://linuxidc」。
location / {
root html;
index index.html index.htm;
proxy_pass http://linuxidc;
}3. これで、負荷分散が最初に完了しました。上流の負荷はポーリング(デフォルト)方式で、各リクエストは時系列順に1つずつ異なるバックエンドサーバに振り分けられ、バックエンドサーバがダウンした場合は自動的に排除されます。この方法は簡単で低コストですが。ただし、信頼性が低く、負荷分散が不均一であるという欠点があります。画像サーバー クラスターと純粋な静的ページ サーバー クラスターに適用されます。
さらに、上流には次のような他の配布戦略があります。
ウェイト (重み)
指定轮询几率，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（权重）
指定轮询几率，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 負荷分散アルゴリズムの概要 (コード付き)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
