どのクライアントを使用しているかわかりません。さまざまなクライアントに分散の最も基本的な実装がありますが、これらはクライアント実装であり、ノードを追加および削除するときは、自分でハッシュを再計算してデータを移行する必要があります。 Redis 3 ではサーバーがサポートされるため、作業が大幅に簡素化されます。

基本的に、現在のクライアント実装は @TechAd が述べたように一貫したハッシュに基づいています。たとえば、Ruby クライアントでは、ニーズに応じて 4G データを 2 つのマシンに分割することも非常に簡単です。はすでに https://github.com/yankov/redis-migra... で直接使用できます。実装を見てみましょう。実際は非常に簡単です。

お役に立てば幸いです。

一貫したハッシュの関連アルゴリズムを検索することをお勧めします。一般的なアイデアは、クライアント上でルートを作成し、キーのハッシュを作成してから、mod 2 を実行し、キーと値を 2 つのマシンに 0 と 1 に保存することです。と読んでください 取り出すときも同様です。 memcache を参照し、参照リンク http://blogread.cn/it/article/5271 を提供できます

3L アプローチを使用することもできます。または、最も直接的な方法は、データをビジネス層で分離して構成に書き込むことです。これは、将来分割するときに非常に便利で、本当に必要な場合はロジックが簡単です。分散を行うため、mongoDBを使用することをお勧めします

pepline が必要ない場合は、https://github.com/twitter/twemproxy Twitter 終了プロキシ、自動ハッシュ、失敗時の自動切り替えを使用することをお勧めします

お聞きしたいのですが、twemproxy はアクティブとスタンバイの自動切り替えをサポートしていませんか?

結果として、このデータ転送を行うために Redis クラスターが使用される場合は、その公式のメディアを参照してください:
既存のデータセットが N 個のマスターに分割されていると仮定すると (既存のシャーディングがない場合は N=1)、データセットを Redis クラスターに移行するには次の手順が必要です。
クライアントを止めてください。現在、Redis クラスターへの自動ライブ マイグレーションはできません。アプリケーション/環境のコンテキストでライブ マイグレーションを調整して実行できる場合があります。
BGREWRITEAOF コマンドを使用して、N 個のマスターすべてに対して追加専用ファイルを生成し、AOF ファイルが完全に生成されるのを待ちます。
AOF ファイルを aof-1 から aof-N までの場所に保存します。この時点で、必要に応じて古いインスタンスを停止できます (仮想化されていない展開では同じコンピューターを再利用する必要があることが多いため、これは便利です)。 N 個のマスターと 0 個のスレーブで構成される Redis クラスターを作成します。後でスレーブを追加します。すべてのノードが永続化のために追加専用ファイルを使用していることを確認してください。
すべてのクラスターノードを停止し、その追加専用ファイルを既存の追加専用ファイルで置き換えます (最初のノードは aof-1、2 番目のノードは aof-2、最大 aof-N)。 新しい AOF ファイルを使用して Redis クラスター ノードを再起動します。彼らは、設定に従ってそこにあるべきではないキーがあると苦情を言うでしょう。
redis-trib fix コマンドを使用してクラスターを修正し、各ノードが権限のあるハッシュ スロットに従ってキーが移行されるようにします。
最後に redis-trib チェックを使用して、クラスターが正常であることを確認します。
Redis Cluster 対応クライアント ライブラリを使用するように変更されたクライアントを再起動します。w