Redis パーティションの実装原理の紹介

Redis パーティショニングは Redis パーティショニングです。簡単に言うと、データを異なる 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 インスタンスにマップすることができます。

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

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

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

格納したいデータのキーを範囲に応じて分割できない場合はどうすればよいですか?たとえば、キーが一連の 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 と Memcached エージェント Twemoroxy はどちらもエージェント パーティショニングを実装します。

クエリ ルーティング

クエリ ルーティングは、Redis Cluster によって実装される Redis パーティショニング メソッドです:

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

Redis パーティショニングの欠点

Redis パーティショニングはこれまでのところ非常に優れていますが、Redis パーティショニングにはいくつかの致命的な欠点があり、そのため一部の Redis 関数がパーティショニングで失敗します。この環境ではうまく機能しません。見てみましょう:

マルチキー操作はサポートされていません。たとえば、バッチで操作したいキーは、異なる Redis インスタンスにマッピングされています。

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

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

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

マシンの追加と削除は非常に複雑です。たとえば、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 インスタンスの数が変わらないことを保証し、マシンの拡張という目的を達成できます。

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

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

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

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

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

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

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

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

概要

この記事では、Redis パーティションの概念を理解した上で、Redis パーティションの一般的な実装方法と原則をいくつか紹介し、最後に、実装で遭遇する問題に基づいて Pre を紹介します。 . -シャーディングソリューション。

関連する推奨事項:

mysql ビデオ チュートリアル: https://www.php.cn/course/list/51.html

# #

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