複数の負荷分散テクノロジーの共有

負荷分散技術は、中規模および大規模な Web サイトのパフォーマンスを向上させる上で大きな利点があります。最近、私は「大規模 Web サイト技術のアーキテクチャ」を勉強しています。この記事では、主にいくつかの負荷分散技術について説明します。皆さんのお役に立てれば幸いです。

[プロトコル層] httpリダイレクションプロトコルは負荷分散を実装します

原理:ユーザーのhttpリクエストに基づいて実際のWebサーバーアドレスを計算し、Webサーバーアドレスをhttpリダイレクト応答に書き込んで返します。ブラウザにアクセスすると、ブラウザは再度アクセスします。

写真に示すように:

利点: 比較的シンプル

: ブラウザは 1 回の訪問を完了するためにサーバーへのリクエストを必要としません。業績不振。

httpリダイレクトサーバー自体の処理能力がボトルネックになる可能性があります。

http302 レスポンス リダイレクトを使用すると、検索エンジンが SEO 不正行為と判断し、検索順位が低下する可能性があります。

【プロトコル層】DNSドメイン名解決負荷分散

原則: DNSサーバー上のIPに対応する複数のドメイン名レコードを設定します。たとえば、ドメイン名 www.baidu.com は、一連の Web サーバー IP アドレスに対応します。ドメイン名解決中に、ドメイン名要求は DNS サーバーのアルゴリズムを通じて適切な実サーバーに割り当てられます。

写真に示すように:

利点: DNS への負荷分散作業を処理することで、Web サイトの管理と負荷分散サーバーのメンテナンスの手間が省けます。同僚の DNS また、地理的位置に基づくドメイン名解決もサポートしています。これにより、ユーザーの地理的位置に最も近いサーバー アドレスにドメイン名が解決され、アクセスが高速化され、パフォーマンスが向上します。

欠点: 現在の DNS 解決はマルチレベル解決です。DNS の各レベルはレコード A をキャッシュする可能性があります。Moyi サーバーがオフラインになっても、そのサーバーに対応する DNS レコード A がまだ存在する可能性があり、その結果、サーバーへのユーザーアクセスに失敗しました。

DNS 負荷分散の制御はドメイン名サービスプロバイダーの手に委ねられており、Web サイトはあまり多くの改善や管理を行うことができない場合があります。

サーバーの処理能力に応じて負荷を分散することができません。 DNS 負荷分散は単純なポーリング アルゴリズムを使用するため、サーバー間の違いを区別できず、サーバーの現在の実行状態を反映できないため、負荷分散効果はあまり良くありません。

追加のネットワーク問題が発生する可能性があります。この DNS サーバーが他の DNS サーバーと適時に対話できるようにし、DNS データが適時に更新され、アドレスがランダムに割り当てられるようにするために、DNS リフレッシュ時間は通常、小さい値に設定されます。小さすぎると、DNS トラフィックが大幅に増加し、追加のネットワーク トラフィックが発生する可能性があります。

[プロトコル層] リバースプロキシ負荷分散

原則: リバースプロキシサーバーは、Web サーバー側にあり、負荷分散機能を提供し、Web サーバーのグループを同時に管理します。負荷分散アルゴリズムに従って、要求されたブラウザ アクセスは別の Web サーバーに転送されて処理され、処理結果はリバース サーバーを介してブラウザに返されます。

写真に示すように:

例: ブラウザーによって要求されたアドレスは、リバース プロキシ サーバーのアドレス 114.100.80.10 です。リバース プロキシ サーバーは要求を受信し、負荷分散アルゴリズムの後に実際の物理アドレス 10.0.03 を取得します。リクエスト結果は実サーバレスサーバに送信され、実サーバで処理された後、リバースプロキシサーバを経由して要求元のユーザに返されます。

利点: http プロトコル レベルでの展開が簡単です。

欠点: リバース プロキシ サーバーを使用すると、Web サーバーのアドレスを外部に直接公開できなくなるため、Web サーバーは外部 IP アドレスを使用する必要がなく、通信ブリッジとしてのリバース プロキシ サービスが必要になります。デュアルネットワークカードと 2 つの外部 IP アドレスと内部 IP アドレスを使用して構成されます。

[ネットワーク層] IP負荷分散

原則: 負荷分散は、ターゲットアドレスを変更することによってネットワーク層で実行されます。

図に示すように:

バランシングサーバーは、アルゴリズムが取得するオペレーティング システムのカーネル プロセスデータが処理された後、応答を受信した後、負荷分散サーバーは自身のアドレスを実サーバー アドレスに変更します。元のユーザーのアクセス アドレス データの返却について話しましょう。逆サーバー負荷分散に似ています。

利点: リクエストに応答する際、リバースサーバー負荷分散よりも高速です。

短所: 大きなデータ (大きなビデオやファイル) をリクエストすると速度が遅くなります。

[リンク層] データリンク層の負荷分散

原則: 負荷分散のためにデータリンク層の Mac アドレスを変更します。

図に示すように:

負荷分散サーバーの IP は、管理する Web サービス グループの仮想 IP と一致します。分散データは配布プロセス中に変更されません。アドレスの IP アドレスにアクセスしますが、MAC アドレスを変更します。これらの 2 つのポイントを通じて、データ パケットの元のアドレスと宛先アドレスを変更せずに通常のアクセスを実現できます。 。

利点: アドレス変換に負荷分散サーバーは必要ありません。 ️データの応答は負荷分散サーバーを経由する必要はありません。

欠点: 負荷分散サーバーのネットワーク カードの帯域幅は比較的高いです。

現在、均等距離負荷分散は、代表的な製品として LVS (Linux Virtual Server) が一般的です。

関連する推奨事項:

Nginx が負荷分散を実現するためのいくつかの方法

以上が複数の負荷分散テクノロジーの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。