定義された後端からサーバのリストをロード・バランシングは、「上流」モジュールは、1台のサーバがユーザの要求を受け入れる選択します。このような基本的な上流のモジュールは、サーバーモジュールは、サーバリストであります：

動的サーバグループ＃
    上流dynamic_zuoyu { 
        サーバーはlocalhost：8080; 7.0 #tomcat 
        サーバーはlocalhost：8081; 8.0 #tomcat 
        サーバーはlocalhost：8082; 8.5 #tomcat 
        サーバーはlocalhost：8083; 9.0 #tomcat 
    }

　　上流のモジュール構成が完了したら、リバースプロキシサーバリストに指定されたアクセスを作るために：

＃他のページは、Tomcatコンテナにリバースプロキシ
        {。LOCATION〜* $ 
            ;インデックスのindex.jspのindex.html 
            ：// dynamic_zuoyu proxy_passのHTTP; 
        }

　　これは、最も基本的な負荷分散のインスタンスですが、実際のニーズを満たすのに十分ではないが、現在、nginxのサーバー上流のモジュールは、分布の6つの方法をサポートしています。

投票	デフォルト
重量	重量道
ip_hash	IPベースのディストリビューション
least_conn	最小接続
フェア（サードパーティ）	応答時間の道
url_hash（サードパーティ）	URLベースのディストリビューション

　　ここでは、nginxの負荷分散戦略が付属しています唯一の詳細、第三者あまり説明。

1、ポーリング

　　最も基本的な構成は、上記の例では、それは、上流モジュールのデフォルトポリシーをデフォルトの負荷分散され、ポーリング方法です。各要求は個別に時系列的に異なるバックエンドサーバに割り当てられます。

　　これは、次のパラメータがあります。

fail_timeout	max_failsと組み合わせて使用します。
max_fails	この時間内に、そのサーバーのすべての要求は失敗し、サーバーがシャットダウンされると考えていると考えられる場合には失敗の最大数は、パラメータセットfail_timeout時間内に設定します。
fail_time	サーバーがダウンタイムと見なされる時間の長さは、デフォルトは10秒です。
バックアップ	マーク・サーバが待機しています。プライマリサーバが停止すると、要求はここに送信されます。
ダウン	永久的なマーカーサーバーがシャットダウンします。

　　注意：

サーバーがダウンしている場合の世論調査では、サーバーは自動的に拒否されます。
デフォルトの設定は、ポーリングポリシーです。
このポリシーは、サーバー構成、ステートレスおよびファーストトラックサービス利用のために非常に適しています。

2、重量

　　重量的、ポーリング戦略のチャンスに指定されたポーリングに基づいて。例としては、次のとおりです：

＃动态服务器组
    上流dynamic_zuoyu { 
        サーバーはlocalhost：8080重量= 2。7.0 #tomcat 
        サーバーはlocalhost：8081; 8.0 #tomcat 
        サーバーはlocalhost：8082バックアップ。8.5 #tomcat 
        サーバはlocalhost：8083 max_fails = 3 fail_timeout = 20S。#tomcat 9.0 
    }

　　この例では、確率の重みパラメータは、ポーリング、Tomcatの7.0倍、他のサーバがアクセスされる確率であるようなアクセスの値に1 ,;重量比比例のデフォルトの重み値を指定します。

　　注意：

高い要求に割り当てられた重みは、より多くの処理が必要となります。
このポリシーは、least_connとip_hashと組み合わせることができます。
ハードウェア構成の違いが大きくなる例あったが、この戦略は、より適切なサーバです。

3、ip_hash

　　ロードバランサは、クライアントのIPに基づいて指定された割り当て方法によると、この方法は、同じクライアントの要求は、セッションのセッションを確保するために、同じサーバーに送信されていることを保証します。来場者は、各バックエンドサーバーにアクセスするように固定されており、サーバー間で問題のセッションを解決することはできません。

動的サーバグループ＃
    上流dynamic_zuoyu { 
        ip_hash;＃ことを確認し、固定のバックエンドサーバーへの各ゲストアクセス
        サーバはlocalhost：8080重量= 2; 7.0 #tomcat 
        サーバーはlocalhost：8081; 8.0 #tomcat 
        サーバーはlocalhost：8082; 8.5 #tomcat 
        サーバーはlocalhost： = = 3 fail_timeoutのmax_fails 8083 20S; 9.0 #tomcat 
    }

　　注意：

nginxのバージョン1.3.1の前に、ip_hash量（重量）で使用することはできません。
ip_hashバックアップでは使用できません。
なセッションと状態サービス、適したこのポリシー。
サーバが削除されている必要があるときは、手動でダウンしなければなりません。

4、least_conn

　　バックエンドサーバー少ない接続への要求を転送します。それらの負荷が実質的に同じになるようにポーリングアルゴリズムは、要求の平均値は、バックエンドに転送されているが、いくつかの要求は長い時間がかかり、それがバックエンドの負荷が高いことになります。この場合、このようleast_conn私たちはより良い負荷分散効果を得ることができます。

動的サーバグループが＃
    上流dynamic_zuoyu { 
        ; least_conn＃は、バックエンドサーバ少ない接続に要求を転送し
        、7.0 #tomcat 8080重量= 2：サーバーのローカルホスト
        8081; 8.0 #tomcat：サーバーのローカルホスト
        サーバーはlocalhost：8082バックアップ; 8.5 #tomcat 
        ローカルホストサーバー：fail_timeout 3 = 8083 = max_fails 20S; 9.0 #tomcat。
    }

　　注意：

様々な期間の要求処理のための政策をこの負荷分散は、サーバーの過負荷を引き起こします。

5、サードパーティのポリシー

　　サードパーティ製プラグインのロード・バランシング・ポリシーは、サードパーティをインストールする必要があります。

①fair

　　サーバ割当要求の応答時間に応じて、短い応答時間優先順位を割り当てます。

動的サーバグループ＃
    上流dynamic_zuoyu { 
        サーバーはlocalhost：8080; 7.0 #tomcat 
        サーバーはlocalhost：8081; 8.0 #tomcat 
        サーバーはlocalhost：8082; 8.5 #tomcat 
        サーバーはlocalhost：8083; 9.0 #tomcat 
        フェア;＃短い応答時間優先度が割り当てられ得ます
    }

②url_hash

　　同じバックエンドサーバに向けた各URLは、キャッシュヒットで使用するように、割り当て要求の結果にアクセスするURLに押しハッシュ。複数の要求とリソースが不要に複数のダウンロードにつながる、異なるサーバーに到着して、キャッシュヒット率が高く、かつ時間のリソースのいくつかの無駄ではありません。使用url_hash、あなたは（つまり、リソースの要求で、ある）同じURLを作ることができ、同じサーバーに到達するであろう、かつて住んでいたキャッシュ資源は、この要求が受信され、それがキャッシュから読み取ることができます。　

Dynamic Serverのグループ＃
    上流dynamic_zuoyu { 
        ハッシュ$ REQUEST_URI; URL＃は、それぞれが同じバックエンドサーバに向け実装
        サーバーはlocalhost：8080; 7.0 #tomcat 
        サーバーはlocalhost：8081; 8.0 #tomcat 
        サーバーはlocalhost：8082; 8.5 #tomcat 
        サーバーはlocalhost： 8083; 9.0 #tomcat 
    }

第三に、要約

　　上記は、ポーリング及びポーリング重みに加えて、nginxのアルゴリズムに従って異なる負荷分散戦略の実装、の6種類です。実際には、我々は主に、実際の需要を満たすために様々な戦略との組み合わせで、さまざまなシナリオに応じて選択的に使用する必要があります。

ます。https：//my.oschina.net/j4love/blog/3060061で再現

nginxのサーバーの負荷分散戦略