1. nginx のインストール
1. nginx のダウンロード
# wget http://nginx.org/download/nginx-1.2.4.tar.gz
2. TCP モジュール パッチのダウンロード
# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master
ソース コードのホームページ: https://github.com/yaoweibin/nginx_tcp_proxy_module
3. nginx
# tar xvf nginx-1.2.4.tar.gz # tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz # cd nginx-1.2.4 # patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch #./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/ # make # make install
2. 設定ファイルを変更します
nginx を変更します.conf 設定ファイル
# cd /usr/local/nginx/conf # vim nginx.conf
worker_processes 1; events { worker_connections 1024; } tcp { upstream mssql { server 10.0.1.201:1433; server 10.0.1.202:1433; check interval=3000 rise=2 fall=5 timeout=1000; } server { listen 1433; server_name 10.0.1.212; proxy_pass mssql; } }
3. nginx
# cd /usr/local/nginx/sbin/ # ./nginx
View 1433 ポートを開始します:
#lsof :1433
4. テスト
# telnet 10.0.1.201 1433
5. SQL サーバー クライアント ツールを使用してテスト
6. TCP ロード バランシングの実行原理
nginx は、リスニング ポートから新しいクライアント リンクを受信すると、すぐにルーティング スケジューリング アルゴリズムを実行し、接続する必要がある指定されたサービス IP を取得して、指定されたサーバーへの新しいアップストリーム接続を作成します。
ps: サービスの堅牢性モニタリング
tcp ロード バランシング モジュールは、組み込みの堅牢性検出をサポートしています。上流サーバーが proxy_connect_timeout で設定された時間を超えて tcp 接続を拒否した場合、期限が切れたものとみなされます。この場合、nginx はすぐにアップストリーム グループ内の別の通常のサーバーへの接続を試みます。接続失敗情報はnginxエラーログに記録されます。 (2) 「よく使用される」データを事前に準備し、サービスを積極的に「プレヒート」し、プレヒート完了後にサーバーへのアクセスをオープンします。
TCP ロード バランシング モジュールは、組み込みの堅牢性検出をサポートしています。上流サーバーが proxy_connect_timeout で設定された時間を超えて TCP 接続を拒否した場合、失敗したものとみなされます。この場合、nginx はすぐにアップストリーム グループ内の別の通常のサーバーへの接続を試みます。接続失敗情報はnginxエラーログに記録されます。
サーバーが繰り返し失敗した場合(max_failsまたはfail_timeoutで設定されたパラメータを超えた場合)、nginxはサーバーもキックします。サーバーが起動されてから 60 秒後、nginx はサーバーが通常に戻っているかどうかを確認するために時々再接続を試みます。サーバーが正常に戻ると、nginx はそのサーバーをアップストリーム グループに追加し、接続リクエストの割合を徐々に増やします。
「徐々に増加している」理由は、通常、サービスには「ホット データ」があるためです。つまり、リクエストの 80% 以上、またはそれ以上が実際に「ホット データ キャッシュ」でブロックされるためです。 、実際に処理されるのはリクエストのほんの一部だけです。マシンが起動したばかりのときは、実際には「ホット データ キャッシュ」が確立されておらず、この時点で大量のリクエストが爆発的に転送されるため、マシンが耐えられなくなり、再びハングアップする可能性があります。 。 mysql を例にとると、通常、mysql クエリの 95% 以上がメモリ キャッシュに分類され、実際に実行されるクエリはそれほど多くありません。
実際には、単一マシンであってもクラスターであっても、同時要求の多いシナリオでの再起動や切り替えにはこのリスクが伴います。これを解決するには主に 2 つの方法があります:
(1 ) リクエストは、少ない状態から多い状態へと徐々に増加し、ホットスポット データが徐々に蓄積され、最終的には通常のサービス状態に達します。
(2) 「よく使用される」データを事前に準備し、サービスを積極的に「プレヒート」し、プレヒート完了後にサーバーへのアクセスをオープンします。
tcp ロード バランシングの原理は lvs の原理と同じで、より低いレベルで動作し、そのパフォーマンスは元の http ロード バランシングよりもはるかに高くなります。ただし、lvs よりも優れているわけではなく、lvs はカーネル モジュール内に配置されますが、nginx はユーザー モードで動作し、nginx は比較的重いです。もう一つ、非常に残念なのが、このモジュールが有料機能であることです。
以上がNginxサーバーでTCPの負荷分散を構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。