1つのロードバランシングの役割
高並行性の問題に対処
ロードバランシングは：それは安くて効果的かつ透明性の方法を提供し、既存のネットワークアーキテクチャ上に構築扩展网络设备、および服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
ロードバランシングなど、複数のオペレーティング・ユニットの上に広がりが実行することを意味し、ロードバランス、英語名：一緒にタスクを完了するように仕事にと、Webサーバ、FTPサーバ、エンタープライズ・クリティカルなアプリケーションサーバや他のミッションクリティカルなサーバ、。
ロードバランシングは、すべての要求まず、ロードバランサ、ロードバランサ（で使用されているロードバランシングアルゴリズムである轮询、IP绑定）权重サーバークラスタの目的である別のサーバーに分散し、実際の、個々のサーバのクラスタは、圧力を減少させることです。
図2ネットワークモデル
| OSI層 | 機能 | TCP / IPプロトコルスイート。 |
|---|---|---|
| アプリケーション層 | ファイル転送、電子メール、ファイルサービス、仮想端末 | TFTP、HTTP、SNMP、FTP、SMTP、DNS、RIP、Telnetの |
| プレゼンテーション層 | データフォーマット、コード変換、データの暗号化 | 合意ん |
| セッション層 | 持ち上げたり、他の接点との接触を確立します | 合意ん |
传输层 |
提供端对端的接口 |
TCP、UDP |
| ネットワーク層 | データパケットのルーティング | IP、ICMP、OSPF、BGP、IGMP、ARP、RARP |
| データリンク層 | そして、送信フレームは、エラー検出機能アドレスを持っています | SLIP、CSLIP、PPP、MTU、ARP、RARP |
| 物理層 | バイナリデータと物理メディア上のその後の送信データの形で | ISO2110、IEEE802、IEEE802.2 |
4と7つの3負荷分散の違い
四层负载均衡：ネットワークモデルは传输层、主にベースに基づいてTCP（例えば負荷分散を実現するためにパケットLVS、haproxy4つの荷重バランサこと）、パケットの送信元アドレスと宛先アドレスが書き換えられます。
七层负载均衡：ネットワークモデルで应用层基づいてURLか、HTTPロードバランシング、Webサーバを実現するためのプロトコル。
nginxの1.9の後、またサポートしています
四层负载均衡
4負荷分散を欠点
サーバークラスタが実際に使用されている負荷分散を使用した後、この時間は、多くの分散に関連する問題を生成します。
例えば：
- 分散型
Sessionの一貫性 - 分散型の時限タスクスケジューリング
幂等性問題 - 分散型発電
全局 ID 分布式锁ソリューション- 分散構成センター
5 Nginxのconfigureのロードバランシング
Nginxロードバランシングは、アップストリームサーバー（実際のビジネスロジックにアクセスサーバー）を提供し负载均衡、故障转移、失败重试、容错、健康检查などを。
アップストリームサーバー（サーバーにアクセスするための実世界のビジネスロジック）が失敗した場合、他のは、上流のサーバ（サーバにアクセスするための実世界のビジネス・ロジック）に転送することができます。
nginxのが最善である使用しない
失败重试農産物電源やその他の問題へのメカニズムを、マイクロサービスの再試行のメカニズムがあります。
5.1 Upstream Serverロードバランシング
上游服务器：使用して负载均衡器実際のビジネスサーバーに転送
Upstream Server中国語の翻訳上游服务器、負荷がサーバーの設定のバランスをとることを意味し、方言表現（nginxのプロキシサーバが最後に本当の訪問になることです）。
负载均衡算法：設定し、複数のアップストリームサーバー（実際のビジネスロジックにアクセスサーバー）負荷分散メカニズム。
失败重试机制：アップストリームサーバー（実際のビジネスロジックにアクセスサーバ）タイムアウトまたはサーバが存続しない場合は、再試行メカニズムにするかどうか（補償機構を）検討してください。
服务器心跳检测：ときに、上流サーバー（実際のビジネス・ロジックアクセス可能なサーバ）、検出監視|ハートビートを。
5.2 Upstream Serverの設定
###定义上游服务器(需要被nginx真实代理访问的服务器) 默认是轮询机制
upstream test{
server 127.0.0.1:8001;
server 127.0.0.1:8002;
}
server {
listen 80;
server_name www.test.com;
location / {
proxy_pass http://test;
index index.html index.htm;
}
}
リフレッシュNginxは：
/usr/local/nginx/sbin/nginx -s reload
テスト：
6個のロードバランシングアルゴリズム
1、ポーリング（デフォルト）
個別に異なる時間順のバックエンドサービスに割り当てられた各要求は、バックエンドサーバがクラッシュした場合、システムが自動的にユーザーのアクセスは影響を受けないように、障害を取り除きます。
2、重量（重量ポーリング）
weight主に各バックエンドサーバーのパフォーマンスアンバランスな状況に使用訪問に割り当てられた高い値が大きい確率、。または合理的かつ効果的な方法を達成するために、マスターの場合に異なる重みを設定するためにホストのリソースのみを使用しました。
3、
ip_hash
各要求は同じIPからの訪問者は、バックエンドサーバーのアクセスを固定し、かつ効果的に動的なWebの問題解決することができるように、ハッシュ結果アクセスIPに応じて割り当てられているsession共有を。一般的にIPバインディングとして知られています。
4、
fair（第三者）
よりweight、ip_hashアルゴリズムのバランスをよりインテリジェントな負荷、fairアルゴリズムは、バックエンドサーバの応答時間の割り当て要求、短い応答時間優先配分に基づいてページサイズとロード時間インテリジェント負荷分散に基づくことができます。Nginxそれは自分自身をサポートしていませんfair。このスケジューリングアルゴリズムが必要な場合は、あなたがインストールする必要があり、upstream_fairモジュールを。
5、
url_hash（第三者）
アクセスされるURLハッシュ結果割り当て要求、各URLバックエンドサーバに向けられ、バックエンドの効率がさらに向上キャッシュサーバとすることができます。Nginx自分自身をサポートしていませんurl_hash。このスケジューリングアルゴリズムを必要に応じて、あなたがインストールする必要があり、パッケージを。Nginxhash
6.1ポーリング（デフォルト）
個別に異なる時間順のバックエンドサービスに割り当てられた各要求は、バックエンドサーバがクラッシュした場合、システムが自動的にユーザーのアクセスは影響を受けないように、障害を取り除きます。
6.2重 Weight
サーバーは、サーバーの実際の重量に応じて調整することができます。より要求、低い重量、より少ない要求に割り当てられた重みより高いです。デフォルトは1です。
###定义上游服务器(需要被nginx真实代理访问的服务器) 默认是轮询机制
upstream test{
server 127.0.0.1:8001 weight=1;
server 127.0.0.1:8002 weight=2;
}
server {
listen 80;
server_name www.test.com;
location / {
proxy_pass http://test;
index index.html index.htm;
}
}
6.3 IPバインディング ip_hash
各アクセス要求がバックエンドサーバーに同じIPベースの固定アクセスからの訪問者のIPハッシュ結果によって割り当てられ、そしてれます可以有效解决动态网页存在的 session 共享问题。一般的にIPバインディングとして知られています。
###定义上游服务器(需要被nginx真实代理访问的服务器) 默认是轮询机制
upstream test{
server 127.0.0.1:8001;
server 127.0.0.1:8002;
ip_hash;
}
server {
listen 80;
server_name www.test.com;
location / {
proxy_pass http://test;
index index.html index.htm;
}
}
7 Nginxフェールオーバーを設定し
場合には、上流のサーバ（サーバへの実際のアクセス）障害がタイムリーまたは適切ではないと、それは、高可用性サーバーを確保するために、次のサーバに直接回転にする必要があります。
Nginx 構成コード：
###定义上游服务器(需要被nginx真实代理访问的服务器) 默认是轮询机制
upstream test{
server 127.0.0.1:8001;
server 127.0.0.1:8002;
}
server {
listen 80;
server_name www.test.com;
location / {
### 指定上游服务器负载均衡服务器
proxy_pass http://test;
### nginx与上游服务器(真实访问的服务器)超时时间 后端服务器连接的超时时间_发起握手等候响应超时时间
proxy_connect_timeout 1s;
### nginx发送给上游服务器(真实访问的服务器)超时时间
proxy_send_timeout 1s;
### nginx接受上游服务器(真实访问的服务器)超时时间
proxy_read_timeout 1s;
index index.html index.htm;
}
}
8 Nginx rewrite
Nginxグローバル変数は達成正規表現とフラグと組み合わせて、自分の最大の変数またはセットを提供url書き換えるとリダイレクト。rewriteだけにserver{}、location{}、if{}、とだけ外に除去名の後ろに渡された文字列パラメータとして働きます。
Rewrite主な機能は実現することであるURL書き換えルールを採用し、あなたが必要な場合は互換の正規表現構文は、一致するルール機能を、コンパイラを、私たちは、コンパイルしてインストールする必要があります前に、ライブラリを。NginxRewritePcreperlNginxRewriteNginxPCRE
Rewrite規則、規範化を図ることができるURL可変行うによれば、URLステアリングの構成及び選択。
8.1 Rewriteグローバル変数
ルールを書き換えるnginxの必要な書き換え、その後、定期的なマッチング要求のURLを使用することであると定義された規則に従って変更ngx_http_rewrite_moduleサポートするためのモジュールをurl書き換え、モジュールは、デフォルトでインストール標準モジュールです。
| 変数 | 意味 |
|---|---|
$args |
この変数はで、パラメータ要求ラインに等しいです。 $query_string |
$content length |
リクエストヘッダContent-lengthフィールド |
$content_type |
リクエストヘッダContent-Typeフィールド |
$document_root |
値は、現在の要求命令ルートに指定しました |
$host |
ホストリクエストヘッダフィールド、そうでない場合は、サーバー名 |
$http_user_agent |
クライアントagent情報 |
$http_cookie |
クライアントcookie情報 |
$limit_rate |
この変数は、接続速度を制限することができます |
$request_method |
クライアント要求の操作、一般的にGETまたはPOST |
$remote_addr |
クライアントのIPアドレス |
$remote_port |
クライアントのポート |
$remote_user |
すでに後にAuth Basic Module認証されたユーザー名 |
$request_filename |
現在の要求のファイルパス、またはルートURI生成指示エイリアスによって要求 |
$scheme |
HTTP方法（例えばhttp、https） |
$server_protocol |
プロトコル要求、通常HTTP/1.0またはHTTP/1.1 |
$server_addr |
システムコールの完了後にサーバのアドレスは、この値を決定することができます |
$server_name |
サーバー名 |
$server_port |
要求は、サーバーのポート番号に達します |
$request_uri |
リクエストからオリジナルのパラメータURIのようなホスト名が含まれていません、/foo/bar.php?arg=baz |
$uri |
なし現在のリクエストパラメータを使用するとURI、$uriそれはホスト名などが含まれていません。/foo/bar.html |
$document_uri |
$uri同じ |
8.2決定IP元のアドレスを
## 如果访问的ip地址为192.168.5.165,则返回403
if ($remote_addr = 192.168.5.166) {
return 403;
}
8.3ブラウザのアクセスを制限します
## 不允许谷歌浏览器访问 如果是谷歌浏览器返回500
if ($http_user_agent ~ Chrome) {
return 500;
}
