Redis パーティションの実装

パーティショニングはデータを複数の Redis インスタンスに分割するプロセスであるため、各インスタンスはキーのサブセットのみを保存します。この記事では、redis がパーティショニングを実装する方法を紹介します。

なぜパーティションを分割する必要があるのでしょうか?分割の動機は何ですか?

1. パフォーマンスの向上: 単一マシンの Redis のネットワーク I/O 機能とコンピューティング リソースは限られており、リクエストは複数のマシンに分散されます。複数のマシンのコンピューティング能力とネットワーク帯域幅を最大限に活用することで、Redis の全体的なサービス機能が向上します。

2. ストレージの水平拡張 Redis のサービス機能がアプリケーションのニーズを満たすことができても、ストレージ データが増加すると、1 台のマシンではマシン自体のストレージ容量が制限され、データが分散します。上部ストレージにより、Redis サービスを水平方向に拡張できます。

一般に、パーティション分割により、単一コンピュータのハードウェア リソースによって制限されるという当初の問題はなくなります。ストレージが不足していますか?コンピューティング リソースが足りませんか?帯域幅が足りませんか?マシンを追加することで、これらの問題を解決できます。

Redis パーティションの基本

実際のアプリケーションでのパーティション分割には多くの具体的な戦略があります。たとえば、すでに 4 つの Redis インスタンス (R0、R1) のセットがあるとします。 、R2、R3。さらに、user:1、user:2 など、ユーザーを表すキーのバッチがあります。「user:」の後の数字はユーザーの ID を表します。これらのキーは 4 つの異なる Redis インスタンスに保存されます。 ＃＃＃＃＃＃どうやってするの？最も簡単な方法はレンジ パーティショニングです。レンジ パーティショニングに基づいてそれを行う方法を見てみましょう。

いわゆるレンジ パーティショニングでは、範囲内のすべてのキーを同じ Redis インスタンスにマップします。データ セットの追加は、前述のユーザー データと同様です。

ユーザー ID が 0 ～ 10000 のユーザー データを R0 インスタンスにマッピングし、ユーザー ID が 10001 ～ 20000 のオブジェクトを R1 インスタンスにマッピングすることができます。

この方法はシンプルで実際のアプリケーションでは非常に効果的ですが、まだ問題があります:

1. 間のマッピング関係を保存するために使用されるテーブルが必要です。ユーザー ID の範囲と Redis インスタンス。たとえば、ユーザー ID 0 ～ 10000 は R0 インスタンスにマッピングされます。

2. このテーブルを維持する必要があるだけでなく、オブジェクト タイプごとにそのようなテーブルも必要です。たとえば、現在ユーザー情報を保存しています。注文情報を保存している場合は、別のマッピングを行います。テーブルを作成する必要があります。

3. 保存したいデータのキーが範囲に応じて分割できない場合はどうしますか? たとえば、キーが UUID のセットである場合、この時点では範囲分割を使用するのは困難です。

レンジ パーティションと比較したハッシュ パーティションの明らかな利点は、レンジ パーティションとは異なり、ハッシュ パーティションがあらゆる形式のキーに適していることです。 object_name: は object_name: であり、パーティショニング方法も非常に単純です。式で表すことができます:

id=hash(key)%N

ここで、id は Redis インスタンスの番号を表します。式は、次の内容に基づいて最初のステップを説明します。キーとハッシュ関数 (crc32 関数など) で数値を計算します。上記の例に従うと、処理する最初のキーは user:1 で、ハッシュ (user:1) の結果は 93024922 になります。

Then the hash result is modulo. modulo の目的は、0 から 3 までの値を計算することであり、この値を Redis インスタンスの 1 つにマッピングできます。たとえば、93024922%4 の結果が 2 であれば、foobar は R2 に保存されることがわかります。

パーティションは、Redis ソフトウェア スタックのさまざまな部分に実装できます。次の点を見てみましょう:

クライアント実装とは、次の図に示すように、キーが Redis インスタンスに保存される Redis クライアント上で決定されることを意味します。

エージェントによる Redis パーティションの実装の概略図は次のとおりです:

クエリ ルーティング プロセス中に、クエリ リクエストを任意の Redis インスタンスにランダムに送信できます。この Redis インスタンスが担当します。 Redis インスタンスの正しいリクエストに転送します。 Redis クラスターは、クエリ ルーティングのためにクライアントと連携するハイブリッドを実装します。

Redis パーティションの欠点

Redis パーティショニングはこれまでのところ非常に優れていますが、Redis パーティショニングにはいくつかの致命的な欠点があり、そのため一部の Redis 機能がパーティショニングされた環境で適切に動作しません。たとえば、バッチで操作したいキーは異なる Redis インスタンスにマッピングされます。

2. マルチキー Redis トランザクションはサポートされていません。

3. パーティション分割の最小粒度がキーであるため、キーに関連付けられた大規模なデータ セットを異なるインスタンスにマップすることはできません。

4. パーティショニングを適用すると、複数の rdb/aof ファイルを処理したり、異なるインスタンスに分散したファイルをバックアップ用に収集したりする必要があるなど、データ処理が非常に複雑になります。

5. マシンの追加と削除は非常に複雑です。たとえば、Redis クラスターは、マシンの追加または削減に必要なほぼランタイム透過的なリバランスをサポートしています。ただし、この機能のクライアントおよびプロキシのパーティショニングなどの方法はサポートされていません。

データのパーティション化は、データ永続ストレージであってもキャッシュであっても、概念的には Redis と同じですが、データの場合、永続ストレージには引き続き大きな制限。

Redis を永続ストレージとして使用する場合、各キーは常に同じ Redis インスタンスにマップされる必要があります。 Redis をキャッシュとして使用する場合、このキーについて、1 つのインスタンスが使用できない場合、このキーを他のインスタンスにマッピングすることもできます。

一貫性のあるハッシュの実装では、通常、キーがマップされているインスタンスが使用できなくなったときに、キーを別のインスタンスにマップすることができます。同様に、マシンが追加された場合、キーの一部は新しいマシンにマッピングされます。理解する必要がある 2 つの点は次のとおりです:

1. Redis がキャッシュとして使用され、要件が次のとおりである場合easy コンシステント ハッシュを使用すると、マシンの追加または削除が非常に簡単になります。

2. Redis を (永続) ストレージとして使用する場合、固定のキーとインスタンスのマッピングが必要となるため、マシンを柔軟に追加または削除できなくなります。それ以外の場合は、マシンの追加または削除時にシステムが再バランスできるようにする必要があります。これは現在 Redis クラスターでサポートされています。

上記の紹介を通じて、Redis パーティションのアプリケーションに問題があることがわかりました。Redis をキャッシュとしてのみ使用しない限り、マシンの追加や削除が非常に面倒です。

ただし、通常、実際のアプリケーションでは Redis の容量変更が非常に一般的です。たとえば、今日は 10 台の Redis マシンが必要ですが、明日は 50 台のマシンが必要になる可能性があります。

Redis が非常に軽量なサービス (各インスタンスが占有するのは 1M のみ) であることを考慮すると、上記の問題に対する簡単な解決策は次のとおりです:

Redis インスタンスを移動するにはどうすればよいですか? Redis インスタンスを独立したマシンに移動する必要がある場合は、次の手順で実行できます:

1. 新しい物理マシンで新しい Redis インスタンスを起動します。

2. 新しい物理マシンを移動するスレーブ マシンとして使用します。

3. クライアントを停止します。

4. 移動する Redis インスタンスの IP アドレスを更新します。

5. SLAVEOF ON ONE コマンドをスレーブ マシンに送信します。

6. 新しい IP を使用して Redis クライアントを起動します。

7. 使用されなくなった Redis インスタンスを閉じます。

redis の詳細については、

列に注目してください。

以上がRedis パーティションの実装の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。