ngx_http_upstream_module

複数のサーバーをサーバーグループとして定義するために使用されます。サーバーグループは、proxy_passおよびfastcgi_pass命令によって呼び出されます。

アップストリーム名

バックエンドサーバーグループを定義します。サーバーはさまざまなポートでリッスンできます。デフォルトはwrrアルゴリズムです。httpでのみ使用できます


    upstream websrv {
    
    
	server 11.2.2.228:80;
	server 11.2.3.63:80;  
}

[root@nginx a]# curl http://www.a.com
11.2.2.228
[root@nginx a]# curl http://www.a.com
11.2.3.63


# 在禁止一台服务之后，nginx会一直将请求反代到正常的主机上去
[root@localhost ~]# systemctl stop httpd
[root@localhost ~]# curl http://www.a.com/index.html
11.2.3.63


两个主机也可以监听的端口不同。
upstream websrv {
    
    
	server 11.2.3.63:80;
	server 11.2.2.228:8080;
}

[root@nginx a]# curl http://www.a.com
11.2.3.63
[root@nginx a]# curl http://www.a.com
11.2.2.228

サーバーアドレス[パラメーター]

アップストリームでサーバーアドレスとそのパラメーターを定義する

いくつかのパラメータがあります

パラメータ	説明
重量=数	重みを設定します。デフォルトは1です。
max_conns = number	バックエンドサーバーへの同時接続の最大数。デフォルト値は0、無制限
max_fails = number	失敗した試行の数がここで指定された数を超える場合、サーバーは使用不可として指定されます。デフォルトは1です
fail_timeout = time	バックエンドサーバーが使用不可としてマークされている場合の接続タイムアウト期間。デフォルトは10です。
バックアップ	サーバーを「スタンバイ」としてマークします。つまり、すべてのサーバーが使用できない場合に有効にします。
ダウン	利用不可としてマークし、ip_hashと協力してグレーリリースを実現します

PS：fail_timeoutは、バックエンドサーバーに接続するときのタイムアウト期間を指定します。max_failsは、fail_timeoutが失敗した後に試行する必要がある試行回数です。

例：

[root@nginx conf.d]# cat a.com.conf
upstream websrv {
    
    
	server 11.2.3.63:80 weight=2 max_fails=3 fail_timeout=20s;
	server 11.2.2.228:8080 weight=1 max_fails=3 fail_timeout=20s;
}

ip_hash

送信元アドレスハッシュスケジューリングアルゴリズム。最初のアクセスがスケジュールされているバックエンドサーバーへのアクセスがスケジュールされている

ダウンで使用します。グレーリリースを実現します。

[root@nginx conf.d]# cat a.com.conf
upstream websrv {
    
    
	ip_hash;
	server 192.168.199.103:80 weight=2 max_fails=3 fail_timeout=20s;
	server 192.168.199.132:8080 weight=1 max_fails=3 fail_timeout=20s;
}
[root@localhost ~]# curl http://www.a.com/index.html
192.168.199.103
[root@localhost ~]# curl http://www.a.com/index.html
192.168.199.103

less_conn

最小の接続スケジューリングアルゴリズム。サーバーの重みが異なる場合はwlcであり、すべてのバックエンドホストの接続数が同じ場合はwrrが使用されます。これは、長い接続に適しています。

例：

[root@localhost ~]# for i in {1..100};do sleep 1; curl http://www.a.com/index.html;done
192.168.199.103
192.168.199.103
192.168.199.132
192.168.199.103
192.168.199.103
192.168.199.132

ハッシュキー[一貫性]

リクエストのスケジューリングは、指定されたキーのハッシュテーブルに基づいて実装されます。ここでのキーは、直接テキスト、変数、または2つの組み合わせにすることができます。
リクエストを分類すると、同じタイプのリクエストが、コンシステントを使用して同じアップストリームサーバーに送信されます。パラメータは、ケタマコンシステントハッシュアルゴリズムを使用します。バックエンドがキャッシュサーバー（ワニスなど）の場合に使用するのに適しています。

ハッシュキーアルゴリズム

たとえば、要求されたURIに対してハッシュ計算を実行して、キャッシュヒット率を大幅に向上させます。
アルゴリズムは、要求されたURIに対してハッシュ計算を実行して値を取得し、それをバックエンドサーバーの重みで除算してモジュラスを取得することです。モジュラスを取得した後に取得された数値は、サーバーによって設定された重みと一致します。たとえば、バックエンドサーバーの重みが1と2の場合、ハッシュ値を3で割ってモジュラスを取得します。モジュラスが1の場合、1のキャッシュに送信されます。2は2に対応するキャッシュサーバーに送信されます。これにより、キャッシュヒット率が大幅に向上します

ただし、これには問題があります。バックエンドキャッシュサーバーを増減すると、既存のキャッシュがヒットせず、キャッシュの受け渡しに失敗し、バックエンドサーバーホストにすべてのプレッシャーがかかります。これはハッシュペネトレーションと呼ばれます。

ハッシュコンセンサスアルゴリズム

テイク$request_uri例を。
最初にリングを作成しましょう1，2，3...2^32-1。このリングにあります。次に、重みに応じてバックエンドキャッシュサーバーIPに乱数を追加し、新しい仮想IPを生成します。そして、新しいIPアドレスのハッシュを計算します。次に2\^32、モジュラスを取ります。このようにして得られたモジュラスを使用して、バックエンドキャッシュサーバーをリング上の対応する番号に配置できます。次に、要求されたURIがハッシュされ、2\^32モジュロが取得されます。それに最も近いキャッシュサーバーは、キャッシュを提供するサーバーです。しかし、これは問題を引き起こします。リング上のrequest_uri同じキャッシュサーバーの近くに多くのモジュラス値があり、キャッシュサーバーに過度のストレスがかかる可能性があります。これはハッシュリングオフセットと呼ばれます。

これに対する解決策は、キャッシュサーバーのモジュラスを取得する前に多数の乗算を実行して、リング上のすべての場所に均等に分散させることです。

後で説明するために写真を追加します。

nginx之upstream