この記事はWeChatパブリックアカウント「Full-Stack Cultivation Road」から転載されたもので、著者はAbao兄弟です。この記事を転載する場合は、Full Stack Xiuxian Road の公開アカウントにご連絡ください。 一貫性ハッシュを理解するには、まず従来のハッシュと大規模分散システムにおけるその限界を理解する必要があります。簡単に言えば、ハッシュとはキーと値のペアのストレージであり、キーを指定すると、関連付けられた値を非常に効率的に見つけることができます。郵便番号に基づいて都市の通りの名前を検索するとします。最も単純な実装の1つは、この情報をハッシュ辞書の形式で保存することです。 データが 1 つのノードまたはマシンに保存するには大きすぎる場合、およびデータを保存するにはシステム内に複数のノードまたはマシンが必要な場合、問題はさらに興味深いものになります。たとえば、複数の Web キャッシュ ミドルウェアを使用するシステムなどです。では、どのキーがどのノードに保存されているかをどのように判断するのでしょうか? この問題の最も簡単な解決策は、ハッシュ係数を使用して判断することです。 キーが与えられたら、そのキーをハッシュし、それをシステム内のノードの数で割って、そのノードにキーを配置します。同様に、キーを取得するときは、キーをハッシュし、ノード数で割って、そのノードに移動して値を取得します。上記のプロセスに対応するハッシュ アルゴリズムは次のように定義されます。
次の図は、マルチノード システムにおける従来のハッシュ モジュラス アルゴリズムを示しています。これに基づいて、単純な負荷分散を実現できます。 1. 従来のハッシュ係数アルゴリズムの限界 従来のハッシュと大規模分散システムにおけるその限界を分析してみましょう。ここでは、前回の記事「Bloom filter development tool youworthy」で定義した SimpleHash クラスを直接使用し、3 つのキー semlinker、kakuqo、test に対してハッシュ操作を実行して、残りを取得します。具体的なコードは次のとおりです。
上記のコードが正常に実行されると、コンソールに次の結果が出力されます。
上記の出力に基づいて、次のテーブルを作成できます。 1.1 ノード削減シナリオ 分散型マルチノード システムでは、障害はよく発生します。事前の通知なしにノードに障害が発生する場合があります。この場合、システムのパフォーマンスが低下するだけで、通常の機能には影響がないと予想されます。 元の例では、ノードに障害が発生すると何が起こるでしょうか? 元の例では、3 つのノードがあります。そのうちの 1 つに障害が発生したとします。このとき、ノードの数は 3 から 2 に変わります。このとき、テーブルの状態は次のように変わります。 ノードの削減により、キーとノードのマッピング関係が変化することは明らかです。この変更は新しいキーには影響しませんが、既存のキーに対してノード マッピング エラーが発生します。「semlinker」を例に挙げます。変更前、システムには 3 つのノードがあり、キーに対応するノード番号は 1 でした。障害が発生すると、ノード数は 2 に減少し、キーに対応するノード番号は 0 になりました。 1.2 ノード追加シナリオ 分散型マルチノード システムでは、休日のプロモーションなどのシナリオでは、突然のトラフィックに対処するためにサービス ノードの容量を拡張する必要があります。 元の例の場合、ノードを追加すると何が起こるでしょうか? 元の例では、ノードは 3 つあります。容量拡張のために 1 つのノードを一時的に追加するとします。このとき、ノードの数は 3 から 4 に変わります。このとき、テーブルのステータスは次のように変わります。 当然、ノードの増加はキーとノードのマッピング関係にも変化をもたらします。この変更は新しいキーには影響しませんが、既存のキーに対してノード マッピング エラーを引き起こします。「semlinker」を例にとると、変更前のシステムには 3 つのノードがあり、キーに対応するノード番号は 1 でした。ノードを追加すると、ノード数は 4 に増加し、キーに対応するノード番号は 2 になりました。 クラスター内のノード数が変わると、以前のマッピング ルールが変わる可能性があります。クラスター内の各マシンによって提供されるサービスが同じであれば、影響はありません。ただし、分散キャッシュのようなシステムでは、マッピング ルールの失敗は、前のキャッシュの失敗を意味します。同時に多数のキャッシュ障害が発生すると、「キャッシュ アバランシェ」が発生し、壊滅的な結果を招く可能性があります。 この問題を解決するには、残りのノード上の既存のキーをすべて再配布する必要がありますが、これは非常にコストのかかる操作であり、実行中のシステムに悪影響を与える可能性があります。もちろん、既存のすべてのキーを再配布するという解決策に加えて、一貫性のあるハッシュ アルゴリズムを使用するという、もう 1 つのより良い解決策があります。 2. 一貫性ハッシュアルゴリズム コンシステント ハッシュ アルゴリズムは、1997 年に MIT によって提案されました。これは、サーバーを削除または追加するときに、既存のサービス要求と要求処理サーバー間のマッピング関係をできるだけ変更しない特殊なハッシュ アルゴリズムです。一貫性のあるハッシュは、分散ハッシュ テーブル (DHT) 内の単純なハッシュ アルゴリズムの動的スケーリングの問題を解決します。 2.1 コンシステントハッシュアルゴリズムの利点
仮想ノードを分割した後も物理サーバーの負荷が不均衡な場合は、サーバー間で一部の仮想ノードのストレージ分散を調整するだけで済みます。これにより、データの増加に応じて物理サーバーの数を動的に拡張でき、従来のハッシュ アルゴリズムを使用してすべてのデータを再配布するよりもコストが大幅に削減されます。 2.2 コンシステントハッシュアルゴリズムとハッシュアルゴリズムの関係 一貫性のあるハッシュ アルゴリズムは、ハッシュ アルゴリズムに基づいて提案されています。動的に変化する分散環境では、ハッシュ アルゴリズムはバランス、単調性、分散といういくつかの条件を満たす必要があります。
3. 一貫性ハッシュアルゴリズムの原理 コンシステント ハッシュ アルゴリズムは、コンシステント ハッシュ リングと呼ばれるデータ構造を通じて実装されます。このリングの始点は 0、終点は 2^32 - 1 であり、始点と終点は接続されているため、このリングの整数分布範囲は、次の図に示すように [0, 2^32-1] になります。 3.1 ハッシュリングにオブジェクトを配置する 「semlinker」、「kakuqo」、「lolo」、「fer」という 4 つのオブジェクトがあり、それぞれ o1、o2、o3、o4 と省略され、ハッシュ関数を使用してこのオブジェクトのハッシュ値を計算すると、値の範囲は [0, 2^32-1] になります。 図中のオブジェクトのマッピング関係は次のとおりです。
3.2 サーバーをハッシュリングに配置する 次に、同じハッシュ関数を使用して、サーバーをハッシュ リングに配置します。ハッシュのキーとしてサーバーの IP またはホスト名を選択できるため、各サーバーはハッシュ リング上の位置を決定できます。ここでは、cs1、cs2、cs3 という 3 つのキャッシュ サーバーがあると仮定します。 図中のサーバーのマッピング関係は次のとおりです。
3.3 オブジェクトのサーバーの選択 オブジェクトとサーバーを同じハッシュ リングに配置した後、ハッシュ リングを時計回りに検索して、オブジェクトのハッシュ値に最も近いマシン (オブジェクトが属するマシン) を探します。 o2 オブジェクトを例にとると、順序ニードルで見つかった最も近いサーバーは cs2 なので、サーバー cs2 が o2 オブジェクトをキャッシュします。サーバー cs1 はオブジェクト o1 と o3 をキャッシュし、サーバー cs3 はオブジェクト o4 をキャッシュします。 3.4 サーバーの追加 ビジネス上のニーズにより、サーバー cs4 を追加する必要があるとします。同じハッシュ操作の後、サーバーは最終的に次の図に示すように t1 サーバーと t2 サーバーの間に配置されます。 写真 上記のシナリオでは、サーバー t1 と t2 間のオブジェクトのみを再配布する必要があります。上記の例では、o3 オブジェクトのみを再割り当てする必要があります。つまり、cs4 サーバーに再配置されます。以前に分析したところ、単純なモジュロ方式を使用すると、新しいサーバーが追加されたときにキャッシュの大部分が無効になる可能性があることがわかりました。ただし、一貫性のあるハッシュ アルゴリズムを使用した後は、再割り当てが必要なオブジェクトが少数で済むため、この状況は大幅に改善されます。 3.5 サーバーの削減 cs3 サーバーに障害が発生し、サービスがオフラインになっていると仮定します。このとき、元々 cs3 サーバーに保存されていたオブジェクト o4 を cs2 サーバーに再割り当てする必要があり、他のオブジェクトは元のマシンに保存されたままです。 3.6 仮想ノード ここではコンシステント ハッシュの基本原則を紹介しましたが、新しいサーバーを追加するときにはまだいくつかの問題があります。新しく追加されたサーバー cs4 は、cs1 サーバーの負荷のみを共有します。cs4 サーバーの追加により、サーバー cs2 および cs3 の負荷圧力は軽減されません。 cs4 サーバーのパフォーマンスが元のサーバーと同じかそれ以上である場合、この結果は期待どおりではありません。 この問題に対処するには、仮想ノードを導入することで負荷の不均衡の問題を解決できます。つまり、各物理サーバーは仮想サーバーのグループに仮想化され、仮想サーバーはハッシュ リング上に配置されます。オブジェクトのサーバーを決定する場合は、まずオブジェクトの仮想サーバーを決定し、次に仮想サーバーを使用して物理サーバーを決定する必要があります。 図中、o1、o2はオブジェクト、v1~v6は仮想サーバー、s1~s3は物理サーバーを表しています。 4. 一貫性ハッシュアルゴリズムの実装 ここでは、仮想ノードを使用しない一貫性のあるハッシュ アルゴリズムの実装のみを紹介します。
上記のコードが正常に実行されると、コンソールに次の結果が出力されます。
上記では、仮想ノードを使用しないコンシステント ハッシュ アルゴリズムの実装についてのみ紹介しました。仮想ノードを使用したコンシステント ハッシュ アルゴリズムに興味がある場合は、「コンシステント ハッシュの原則と Java 実装の分析」の記事を参照してください。 V. 結論 この記事では、分散システムにおける従来のハッシュ係数アルゴリズムの限界を例を通して紹介し、この問題の解決策として一貫性ハッシュアルゴリズムを紹介します。コンシステント ハッシュ アルゴリズムは、1997 年に MIT によって提案されました。これは、サーバーを削除または追加するときに、既存のサービス要求と要求処理サーバー間のマッピング関係をできるだけ変更しない特殊なハッシュ アルゴリズムです。コンシステント ハッシュ アルゴリズムの役割と利点、およびその他の関連知識を紹介した後、コンシステント ハッシュ アルゴリズムの原理を図の形でわかりやすく紹介し、最後に仮想ノードを使用しないコンシステント ハッシュ アルゴリズムの Java 実装を示しました。 6. 参考資料 Baidu 百科事典 - 一貫性ハッシュ Zhihu - インタビュー必須: 一貫性のあるハッシュ アルゴリズムとは何ですか? Leo - 一貫性ハッシュの原理の分析 CSDN - 一貫性ハッシュの原理の分析と Java での実装 コードプロジェクト - 一貫性のあるハッシュ |
<<: 私の友人はソーシャルメディアのアルゴリズムの推奨に「誘惑」され、過激なグループに参加しました
ニューラルネットワークがうまく動作しない場合はどうすればいいでしょうか?この記事の著者は、データの前...
最近、有名なChatGPT「おばあちゃんの脆弱性」が再び人気になっています!この伝説の「Granny...
分布外 (OOD) 検出は、オープン ワールド インテリジェント システムの信頼性の高い動作に不可欠...
テスラと「レース」を敢行する四輪ロボットを見たことがありますか?以下に示すように、かなり高速であるよ...
5月16日、天津梅江会議展示センターで第2回世界知能大会が開幕した。アリババグループ取締役会長のジャ...
MITの研究者たちは、人間とロボットのシームレスなコラボレーションに近づく可能性のある新しいシステム...
今日、人工知能技術は社会のあらゆる分野にますます大きな影響を及ぼしており、教育も例外ではありません。...
MNIST 認識の精度は 100% に達しましたか?最近、プレプリントプラットフォームarXivに掲...
導入いくつかの一般的なオプティマイザーを紹介し、その長所と短所を分析し、オプティマイザーを選択するた...
執筆者:ユン・チャオ「今日は、Stack Overflow にとってエキサイティングな新時代の始まり...
現在、AI によって完全に有効化されたプロセスを備えている企業はわずか 25% であり、これらの企業...
AI は、クラウドの管理と運用に大変革をもたらすものとして台頭しています。しかし、AI とクラウド ...
約1週間の不安が去った後、国内のiOSアプリ開発者はようやく落ち着くことができた。中国におけるApp...