Redis パーティションの実装-Redis-php.cn

パーティショニングはデータを複数の 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 インスタンスが担当します。 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 クラスターでサポートされています。

Pre-Sharding

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

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

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

Redis インスタンスが物理マシンの場合、最初に複数のインスタンスを起動できます。 32 インスタンスや 64 インスタンスなどのいくつかのインスタンスを作業クラスターとして選択できます。 1 台の物理マシンに十分なストレージがない場合、一般的なインスタンスを 2 台目の物理マシンに移動して順番にペアにすることで、クラスター内の Redis インスタンスの数が変わらないことを保証し、マシンの拡張という目的を達成できます。