問題が提起します
ハッシュの一貫性とは何ですか?4台のキャッシュサーバが存在すると仮定N0,N1,N2,N3
し、現在のデータを格納する必要がありOBJECT1,OBJECT2,OBJECT3,OBJECT4,OBJECT5,OBJECT5,OBJECT7,OBJECT8
、
我々は4台のサーバーにキャッシュされ、これらのデータを必要とし、適切な質問をされます
データストレージ戦略を設計する方法は?ObjectXは、サーバー上に格納されるべきもの?
我々はいくつかのアイデアを持っているように、この問題を解決するには。
1.残りのハッシュ方式
ハッシュを使用して(Objectx)%4決定サーバノード
仮定hash(OBJECT1)=2
2%4 = 2から、それが発見され、Object1
それはノードに格納されるべきN2
で
想定hash(OBJECT2)=3
4 = 3 3%、それが発見され、Object2
ノードに格納されるべきN3
で
仮定hash(OBJECT3)=1
1%4 = 1から、それが発見され、Object3
それはノードに格納されるべきですN1
上の
仮定hash(OBJECT4)=0
、1%4 = 1から、それが発見され、Object4
それはノードに格納されるべきN0
で
仮定hash(OBJECT5)=5
5%4 = 1から、それが発見され、Object5
それはノードに格納されるべきN1
で
仮定hash(OBJECT6)=6
6%4 = 2から、それが発見され、Object6
それに記憶されなければなりませんノードN2
上の
仮定はhash(OBJECT7)=7
、7%4 = 3から、それが発見され、Object7
ノードはに保存されるべきであるという仮定、8%4 = 0から、それが発見され、その後、ノードが格納されるべきですN3
hash(OBJECT8)=8
Object8
N0
私たちが読む必要があると仮定Object3
して、データをhash(object3)=1
我々は唯一のアクセス・ノードが必要、既知のN1
ことができます。
1.1今と仮定N3
突然の故障オフライン
我々は、再構成キャッシュの問題に直面しています
ハッシュ(Objectx)%3を使用してサーバノードを決定します
仮定hash(OBJECT1)=2
2%3 = 2から、それが発見され、Object1
それはノードに格納されるべきN2
で
想定hash(OBJECT2)=3
3 = 0〜3%だけ、それが発見され、Object2
ノードに格納されるべきN0
で
仮定hash(OBJECT3)=1
1%3 = 1から、それが発見され、Object3
それはノードに格納されるべきですN1
上の
仮定hash(OBJECT4)=0
、0%3 = 0から、それが発見され、Object4
それはノードに格納されるべきN0
で
仮定hash(OBJECT5)=5
5%3 = 2から、それが発見され、Object5
それはノードに格納されるべきN2
で
仮定hash(OBJECT6)=6
6%3 = 0から、それが発見され、Object6
それに格納されなければなりませんノードN0
上の
仮定はhash(OBJECT7)=7
、7%3 = 1から、それが発見され、Object7
ノードはに保存されるべきであるという仮定、8%3 = 2から、それが発見され、その後、ノードが格納されるべきですN1
hash(OBJECT8)=8
Object8
N2
このとき、データの正確性を確保するために、我々は必要な
データをObject2
からN3
への移行N0
データObject5
からN1
への移行N2
データObject6
からN2
への移行N0
データObject7
からN3
への移行N1
データObject8
からN0
への移行N2
1.2は、今、私たちは、新しいサーバーを追加するとしN4
我々は、再構成キャッシュの問題に直面しています
ハッシュ(Objectx)5%を使用してサーバノードを決定します
仮定hash(OBJECT1)=2
2%5 = 2から、それが発見され、Object1
ノードに格納されるべきN2
で
想定hash(OBJECT2)=3
3%5 = 3から、それが発見され、Object2
ノードに格納されるべきN3
で
仮定hash(OBJECT3)=1
1%5 = 1から、それが発見され、Object3
それはノードに格納されるべきですN1
上の
仮定hash(OBJECT4)=0
、0%5 = 0から、それが発見され、Object4
それはノードに格納されるべきN0
で
仮定hash(OBJECT5)=5
5%5 = 0から、それが発見され、Object5
それはノードに格納されるべきN0
で
仮定hash(OBJECT6)=6
6%5 = 1から、それが発見され、Object6
それに記憶されなければなりませんノードN1
上の
仮定はhash(OBJECT7)=7
、7%5 = 2から、それが発見され、Object7
ノードはに保存されるべきであるという仮定、8%5 = 3から、それが発見され、その後、ノードが格納されるべきですN2
hash(OBJECT8)=8
Object8
N3
私たちが必要とするデータの正確性を確保するために、この時、
データObject2
からN3
への移行N0
データObject5
からN1
への移行N0
データObject6
からN2
への移行N1
データObject7
からN3
への移行N2
データObject8
からN0
マイグレーションN3
上記2例からわかるように、マシンの数が変化したら、我々はキャッシュの変更の多くに直面し、他の言葉で、キャッシュの失敗のほとんどは、雪崩につながる可能性が高いです。
2.整合性ハッシュスキーム
今、私たちは次のような戦略を交換します
0 <ハッシュ(Objectx)%8 <= 2、 その後で貯蔵
N0
2 <ハッシュ(Objectx)%8 <= 4、 その後で保存N1
4 <ハッシュ(Objectx)%8 <= 6、 その後で保存しN2
6 <ハッシュ(Objectx )8%<= 8に格納されていますN3
2.1今と仮定N3
突然の故障オフライン
私たちは、再キャッシュ構造の問題に直面して、次のように、調整戦略があります
0 <ハッシュ(Objectx)%8 <= 2、 その後で貯蔵
N0
2 <ハッシュ(Objectx)%8 <= 4、 その後で保存N1
4 <ハッシュ(Objectx)%8 <= 6、 その後で保存しN2
6 <ハッシュ(Objectx )8%<= 8に格納されていますN0
このとき、データの正確性を確保するために、私たちが必要とする
データObjectX
からN3
の移行をN0
、影響を受けたデータのみN3関連データです。
2.2は、今、私たちは、新しいサーバーを追加するとしN4
私たちは、再キャッシュ構造の問題に直面して、次のように、調整戦略があります
0 <ハッシュ(Objectx)%8 <= 2、 その後で貯蔵
N0
2 <ハッシュ(Objectx)%8 <= 4、 その後で保存N1
4 <ハッシュ(Objectx)%8 <= 5、 その後で保存しN2
5 <ハッシュ(Objectx )8%<= 6、その後で保存N4
<ハッシュ(Objectx)%8 6 <= 8、 に格納されていますN3
このとき、データの正確性を確保するために、我々は必要な
データN2
のコピーをN4
影響を受けるだけN2関連するユーザー。
慣行の二種類を比較すると、より優れた視認性シナリオ2シナリオ2は、ハッシュの一貫性であります
2.3の欠点
少数のマシン、各マシンの負荷がより不均一になり、この問題を解決するには、仮想ノードを追加し、あなたは、より多くのデータを想像することができ、次のようにその戦略を調整することで、より均一に分布。
0 <ハッシュ(Objectx)%8 <= 1、 その後で保存し
N0
、1 <ハッシュ(Objectx)%8 <= 2、 その後で貯蔵N1
2 <ハッシュ(Objectx)%8 <= 3、 その後に格納されているN2
3 <ハッシュ(Objectx )%8 <= 4、その後で保存N3
4 <ハッシュ(Objectx)%8 <= 5、 その後で保存しN0
5 <ハッシュ(Objectx)%8 <= 6、 その後で保存しN1
6 <ハッシュ(Objectx)%8 <= 図7に示すように、それが中に記憶されているN2
7 <ハッシュ(Objectx)%8 <= 8、 に格納されていますN3
3.整合性ハッシュの原則
ネットワーク、ノーさらに精緻化の原則にあまりにも多くの。
推奨読書
経験とソースコードを提供ランディングサイトのアドレスを得るために、マイクロチャネルの二次元コードをスイープ
楽屋管理フレームワークのrestgo管理者を行くgolang言語のオープンソースプロジェクト
タッチジェスチャーをサポートしています、あなたはカレンダープラグインの周りにスライドすることができます
あなたは18のインターネットのビジネスモデルを知っている必要があります
推奨読書
経験とソースコードを提供ランディングサイトのアドレスを得るために、マイクロチャネルの二次元コードをスイープ
楽屋管理フレームワークのrestgo管理者を行くgolang言語のオープンソースプロジェクト