Nginx 負荷分散
最近のプロジェクトは同時実行性を念頭に置いて設計する必要があるため、プロジェクト アーキテクチャを設計する際に、Nginx を使用して Tomcat クラスターを構築し、次に Redis を使用して分散セッションを構築することを検討しました。その探索プロセスを共有します。以下にステップごとに説明します。
Nginx は小さいですが、リバース プロキシ、ロード バランシング、データ キャッシュ、URL 書き換え、読み書き分離、動的と静的分離などをサポートするという点では確かに非常に強力です。次に、負荷分散の構成について説明します。次の記事では、Redis との組み合わせをテストします。
Nginxの負荷分散スケジューリング方法
Nginxの負荷分散モジュール上流モジュールは、主に次の4つのスケジューリングアルゴリズムをサポートしています:
1. サーバーポーリング(デフォルトモード): 各リクエストは時系列順にアクセスされ、異なるリクエストに割り当てられます。バックエンドサーバーがダウンした場合でも、ユーザーのアクセスに影響を与えないように、障害のあるシステムが自動的に排除されます。 Weight はポーリングの重みを指定します。Weight の値が大きいほど、より高いアクセス確率が割り当てられます。主にサーバー側のパフォーマンスが不均一な場合に使用されます。
2. ip_hash: アクセスされた IP のハッシュ値に従って各リクエストが割り当てられます。サーバーが修正された後、同じ IP からのユーザーの行がバックエンドのサーバーに修正されます。 Web ページ上で共有することで問題を効果的に解決できます。
3. 公正: このアルゴリズムは、ページ サイズと読み込み時間に基づいて負荷分散の決定をインテリジェントに行うことができます。つまり、バックエンド サーバーの応答時間に基づいてリクエストを割り当て、応答時間に優先順位を付けます。期間。 Nginx 自体は、fair モジュールに統合されていません。このスケジューリング アルゴリズムが必要な場合は、Nginx のupstream_fair モジュールをダウンロードし、それを設定してロードする必要があります。
4. url_hash: このスケジューリング アルゴリズムは、アクセスした URL のハッシュ結果に基づいてリクエストを割り当てます。これにより、各 URL が同じバックエンド サーバーに送信され、バックエンド サーバーの効率がさらに向上します。 Nginx 自体にはこのモジュールが組み込まれていません。使用する場合は、Nginx のハッシュ パッケージをインストールしてコンパイルし、nginx に読み込む必要があります。
Nginxのアップストリームモジュールでサポートされているステータスパラメータ
httpのアップストリームモジュールでは、serverコマンドを通じてバックエンドサーバーのIPアドレスとポートを指定でき、また、バックエンドサーバーの負荷分散を設定することもできます各バックエンドサーバーのスケジュールのステータス。通常設定されるステータスパラメータは次のとおりです:
1. down: 現在のサーバーが一時的に負荷分散に参加していないことを示します。
2.バックアップ: 予約されたバックアップサーバー。バックアップ サーバーは、バックアップ以外の他のすべてのマシンに障害が発生するかビジー状態になると要求されるため、このサーバーへの負担は最も少なくなります。
3. max_fails: 許可されるリクエスト失敗の数。デフォルトは 1 です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。
4.fail_timeout: max_fails 回の失敗後にサービスを一時停止する時間。 max_fails は、fail_timeout と一緒に使用できます。
注: 負荷分散スケジューリング アルゴリズムが ip_hash を使用する場合、負荷分散スケジューリングにおけるバックエンド サーバーのステータスを重み付けおよびバックアップにすることはできません。
Nginxパラメータの設定と説明
#user nobody; worker_processes 2; error_log logs/error.log; error_log logs/error.log notice; error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.0; gzip_vary on; upstream andy { server 192.168.1.110:8080 weight=1 max_fails=2 fail_timeout=30s; server 192.168.1.111:8080 weight=1 max_fails=2 fail_timeout=30s; ip_hash; } server { listen 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location /andy_server { proxy_next_upstream http_502 http_504 error timeout invalid_header; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://andy; #此处proxy_pass定义的name需要跟upstream 里面定义的name一致 expires 3d; #以下配置可省略 client_max_body_size 10m; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
注: 詳細な設定の説明については、前の記事を参照してください。
Nginx 負荷分散テスト
現在、Nginx は 192.168.1.110 にデプロイされ、Tomcat サーバーは 192.168.1.110 と 192.168.111 にデプロイされています。
1. http://192.168.1.110/andy_server/ を開くと、Nginx ロード クラスターがデフォルト モードを採用している場合、サーバーは毎回ポーリングされます。この方法では、クラスター セッションの問題を解決できません。 この方法は、192.168.1.110 サーバーがダウンした場合、Nginx はリクエストをダウンしていないサーバーに転送します (テスト後、192.168.1.110 サーバーはシャットダウンされ、リクエストは次のサーバーにジャンプします)。 192.168.1.111サーバー)。しかし、ハッシュ化されたサーバーがダウンし、Nginx が別のサーバーに転送されると、当然セッションが失われます。 3. Nginx のインストールに必要な残りの 2 つの対応するモジュールは、上記と同じ方法ではテストされていません。 概要 どの負荷分散方法を使用しても、セッションの損失が発生します。この問題を解決するには、セッションをデータベース、ファイル、または分散メモリ サーバーのいずれかに分けて保存する必要があり、これはクラスタ構築に不可欠です。次の記事では、セッションの問題をテストして解決します 著作権表示: この記事はブロガーによるオリジナルの記事であり、ブロガーの許可なく複製することはできません。
以上、ロードバランシングのための Nginx+Tomcat をその側面も含めて紹介しましたが、PHP チュートリアルに興味のある友人に役立つことを願っています。