redis - Predis シャーディング (コンシステント ハッシュ)

Question

Predis は、クライアント側のシャーディング (キーの一貫したハッシュのサポート) を持っていると主張しています。http://github.com/nrk/predis

プロファイル (ノード) の配列への接続を使用してシャーディングを実行できますが、一貫性のあるハッシュではありません。別のノードをプールに追加すると、一部のキーが見つかりません。誰でもこれについて経験がありますか？

php 5.2 (および redis の php 5.2 バージョン) を使用します。

Answer 1

Redis の公式サイトには、「Redis はコンシステント ハッシュによるクライアント側のシャーディングをサポートしています。現在、フェイル トレランスのサポートも、実行時のクラスターの追加または削除もサポートされていません」と書かれています。

現時点で私が理解していることから、この種の共有は耐障害性がなく、障害が発生したノードに保存されているすべてのキーが失われます。同様に、新しいノードを追加すると、キー スペースの一部が失われます (キーが間違ったノードに保存されるため)。通常、コンシステント ハッシュ システムでは、新しいノードが参加すると、隣接ノードからそのノードにマップされているすべてのキーがコピーされます。これを行うための Redis サーバーのサポートはありません。

そのため、実際のデータが Redis の背後に格納されているキャッシュとして Redis を使用している場合、コンシステント ハッシュは正常に機能しますが、今のところ、データが失われないとは考えないでください。

更新: ketamaと呼ばれる一貫したハッシュ ライブラリを介して実際のシャーディングを実装することが可能です。

Answer 2

解決策は、仮想シャーディングを使用することです。Predisフレームワークが機能するかどうかはわかりませんが、ある種の配列を使用していると予測しています。おそらく、起動時に各シャードに関する情報を入力します。

最大10個のシャードがあると想定します（この数に達する可能性は低いはずです）。次に、3台の実サーバーのみを指すシャーディングアレイを作成します。将来、新しいノードを追加するときに、関連データを新しいシャードに移行し、マッピングを変更します。このアプローチは、フォーム変更ハッシュ関数を保持します。

初期マッピング：

0 => 0 //node #0
1 => 0
2 => 0
3 => 1 //node #1
4 => 1
5 => 1
6 => 2 //node #2
7 => 2
8 => 2
9 => 2

新しいノードを追加するときは、マッピングを変更するだけです。

0 => 0
1 => 0
2 => 3 // new node #3
3 => 1
4 => 1
5 => 3 // new node #3
7 => 2
8 => 2
9 => 3 // new node #3

したがって、h（x）= 9、5、または2のデータをノード＃3に移動する必要があります。