私は正しい軌道に乗っているかどうかを理解しようとしています。私は (リアルタイム) 統計/分析サービスを構築しており、redis を使用していくつかのセットとハッシュを保存しています。
ここで、ある程度の成功があり、スケールアウトする必要があると仮定しましょう。ハッシュ リング手法は良さそうに見えますが、キャッシング シナリオにのみ適しているという印象があります。
ノードがダウンした場合はどうなりますか? 理論的には、その鍵は現在、他のノードによって所有されています。実際には、彼らはデータを持っていません。失われていますよね？ノードの追加/削除と同じです。
基本的なことが欠けていますか？これは貧乏人のクラスターでしょうか？
クラスターで複数のノードを使用する理由は 2 つあります。
この 2 つは根本的に異なりますが、両方を実装できます。コンシステント ハッシュを使用して、単一のノードではなく、標準のマスター/スレーブ セットアップを持つ一連のノードをポイントします。
クラスターがキャッシュではなくプライマリ データ ストアである場合は、データのコピーを含む別の再分散戦略が必要になります。
私の実装は、クライアントがハッシュ用に 64k バケットの 1 つを選択し、そのバケットをノードにマップするテーブルを持つことに基づいています。最初は、すべてがノード #1 にマップされます。
ノード #1 が大きくなりすぎると、そのスレーブがマスター ノード #2 になり、テーブルが更新されてノード #1 キーの半分がノード #2 にマップされます。この時点で、すべての読み取りと書き込みが新しいマッピングで機能するようになり、間違ったノードにあるキーをクリーンアップするだけで済みます。パフォーマンス要件に応じて、すべてのキーを一度にチェックすることも、有効期限システムのようにランダムに選択したキーをチェックすることもできます。