Redis シャーディング (分散キャッシュ)

パーティショニングは、データを複数の Redis インスタンスに分割し、各インスタンスにすべてのキーのサブセットのみが含まれるようにするプロセスです (関連する推奨事項: Redis チュートリアル )

1 シャーディングの用途は何ですか

Redis のシャーディングには 2 つの主な目的があります:

• を組み合わせることを可能にします。大規模なデータベースをサポートするために使用される多くのコンピュータのメモリ。シャーディングを使用しない場合、1 台のマシンがサポートできるメモリ量が制限されます。

• コンピューティング能力を複数のコアまたは複数のサーバーに拡張したり、ネットワーク帯域幅を複数のサーバーまたは複数のネットワーク アダプターに拡張したりできます。

2 シャーディングの基本

さまざまなシャーディング基準 (基準) があります。

4 つの Redis インスタンス R0、R1、R2、R3 があるとします。 、および user:1、user:2 など、ユーザーを表すさらに多くのキーがあります。特定のキーがどのインスタンスに保存されるかを選択するさまざまな方法を見つけることができます。言い換えれば、キーを特定の Redis サーバーにマップするにはさまざまな方法があります。

シャーディングを実行する最も簡単な方法の 1 つは範囲パーティショニングです。これは、オブジェクトの範囲を指定された Redis インスタンスにマッピングすることでシャーディングを完了します。たとえば、ユーザーがインスタンス R0 に ID 0 から ID 10000 まで入力し、ユーザーがインスタンス R1 に ID 10001 から ID 20000 まで入力すると想定できます。

このアプローチは機能し、実際に実際に使用されています。これには、範囲をインスタンスにマップするテーブルが必要になるという欠点があります。

このテーブルは管理する必要があり、さまざまなタイプのオブジェクトにテーブルが必要であるため、Redis では範囲シャーディングはお勧めできません。他のシャーディング代替手段よりも効率が低くなります。

範囲シャーディングの代替手段はハッシュ分割です。

このモードは任意のキーで動作し、キーが object_name: の形式である必要はありません。これと同じくらい簡単です

• ハッシュ関数 (crc32 ハッシュ関数など) を使用して、キー名を数値に変換します。たとえば、キーが foobar の場合、crc32(foobar) は 93024922 のようなものを出力します。

• このデータをモジュロして 0 から 3 までの数値に変換し、その数値を 4 つの Redis インスタンスのいずれかにマッピングできるようにします。 93024922 モジュロ 4 は 2 に等しいため、キー foobar は R2 インスタンスに保存される必要があることがわかります。注: モジュロ演算は除算演算の余りを返します。これは多くのプログラミング言語では常に % 演算子として実装されます。

これら 2 つの例からわかるように、シャーディングには他にも多くの方法があります。ハッシュ シャーディングの高度な形式はコンシステント ハッシュと呼ばれ、一部の Redis クライアントとブローカーによって実装されます。

3 シャーディングの実装 (理論)

シャーディングは、ソフトウェア スタックのさまざまな部分で実行できます。

##•クライアント側パーティショニング

##クライアントは、指定されたキーの書き込みおよび読み取りを行うための正しいノードを直接選択します。多くの Redis クライアントは、クライアント側パーティショニングを実装しています。

• プロキシ支援パーティショニング

私たちのクライアントは、Redis インスタンスに直接リクエストを送信するのではなく、Redis プロトコルを理解できるプロキシにリクエストを送信します。

プロキシは、リクエストが正しい Redis に転送されることを保証します。設定されたシャーディング モードに従ってインスタンスを生成し、クライアントに応答を返します。

Redis と Memcached のプロキシ Twemproxy は、プロキシ支援分割を実装します。

• クエリ ルーティング

Youクエリをランダムなインスタンスに送信でき、このインスタンスはクエリを正しいノードに転送することを保証します。

Redis クラスターは、クライアントの助けを借りてハイブリッド形式のクエリ ルーティングを実装します (リクエストは転送されません) Redis インスタンスから別のインスタンスに直接アクセスできますが、クライアントは正しいノードへのリダイレクトを受け取ります)。

4 シャーディングの欠点

Redis の一部の機能が適切に動作しません。シャーディングあり

• 複数のキーを含む操作は通常サポートされていません。たとえば、2 つの異なる Redis インスタンスにマップされたキーに対して交差を実行することはできません (実際には交差を実行する方法はありますが、直接行うことはできません)。

• 複数のキーが関与するトランザクションでは、

## を使用できません。 #• シャーディングの粒度が重要であるため、大規模な順序セットなどのデータ セットをシャーディングするために大きなキーを使用することはできません

• シャーディングを使用すると、データの処理がより複雑になります。たとえば、複数の RDB/AOF ファイルを処理する必要があり、データをバックアップするときに複数のインスタンスとホストから永続ファイルを集約する必要があります。

• 容量の追加と削除も複雑です。たとえば、Redis Cluster には実行時にノードを動的に追加および削除してデータの透過的な再バランスをサポートする機能がありますが、クライアント側のシャーディングやプロキシなどの他の方法はこの機能をサポートしていません。ただし、この時点で役立つプリシャーディングと呼ばれるテクノロジーがあります。

5 ストレージまたはキャッシュ

Redis のシャーディング概念は、Redis をデータ ストアとして使用する場合でもキャッシュとして使用する場合でも同じですが、データ ストアとして使用する場合には重要な制限があります。 Redis がデータ ストアとして使用される場合、特定のキーは常に同じ Redis インスタンスにマップされます。 Redis をキャッシュとして使用する場合、あるノードが使用できずに別のノードが使用されても大きな問題にはなりません。キーとインスタンスのマッピングを希望に応じて変更することで、システムの可用性 (つまり、システムの機能) が向上します。私たちの質問に答えてください）。

一貫性のあるハッシュの実装では、特定のキーの優先ノードが使用できない場合に、他のノードに切り替えることができます。同様に、新しいノードを追加すると、一部のデータがこの新しいノードに保存され始めます。

ここでの主な概念は次のとおりです:

• Redis をキャッシュとして使用する場合、コンシステント ハッシュを使用してスケールアップとスケールダウンを簡単に実現できます。

• Redis をストレージとして使用する場合、固定のキーとノードのマッピングが使用されるため、ノードの数は固定する必要があり、変更することはできません。それ以外の場合は、ノードを追加または削除するときに、ノード間のキーの再調整をサポートするシステムが必要です。現在、これを実行できるのは Redis クラスターのみです。

6 事前シャーディング

# #シャーディングに関する問題はすでにわかっています。Redis をキャッシュとして使用しない限り、ノードの追加と削除は難しいものです。固定キーとインスタンスのマッピングを使用する方がはるかに簡単です。

ただし、データ ストレージのニーズは常に変化している可能性があります。現在は 10 個の Redis ノード (インスタンス) で生活できますが、明日は 50 個のノードが必要になる可能性があります。

Redis はメモリ使用量がかなり小さく、軽量であるため (アイドル状態のインスタンスは 1 MB のメモリのみを使用します)、簡単な解決策は、最初から多数のインスタンスを起動することです。 1 台のサーバーだけで開始した場合でも、初日に分散世界に住むことを決定し、シャーディングを使用して 1 台のサーバーで複数の Redis インスタンスを実行できます。

最初から多数のインスタンスを選択できます。たとえば、32 または 64 のインスタンスはほとんどのユーザーを満足させ、将来の拡張に十分な余地を提供します。

これにより、データ ストレージの拡大が必要になり、さらに多くの Redis サーバーが必要になった場合に、インスタンスをあるサーバーから別のサーバーに移動するだけで済みます。最初のサーバーを追加するときは、Redis インスタンスの半分を最初のサーバーから 2 番目のサーバーに移動する必要があります。

Redis レプリケーションを使用すると、ダウンタイムをほとんどまたはまったく発生させずにデータを移動できます。

• 新しいサーバーで空のインスタンスを開始します。

• データを移動し、新しいインスタンスをソース インスタンスのスレーブ サービスとして構成します。

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

• 移動されたインスタンスのサーバー IP アドレス構成を更新します。

• 新しいサーバー上のスレーブ ノードに SLAVEOF NO ONE コマンドを送信します。

• 新しく更新された構成でクライアントを起動します。

• 最後に、使用されなくなった古いサーバー上のインスタンスを閉じます。

7 シャーディングの実装 (実践)

これまで、理論的に Redis シャーディングについて説明してきましたが、実際の状況はどうなるのでしょうか?どのようなシステムを使用する必要がありますか?

7.1 Redis クラスター

Redis クラスターは、自動シャーディングと高可用性を実現するための推奨される方法です。

Redis クラスターが利用可能になり、Redis クラスターがサポートされるようになると、クライアントが利用可能になると、Redis Cluster が Redis シャーディングの事実上の標準になります。

Redis クラスターは、クエリ ルーティングとクライアント シャーディングのハイブリッド モデルです。

7.2 Twemproxy

Twemproxy は Twitter によって開発されたプロキシで、Memcached ASCII および Redis プロトコルをサポートします。これはシングルスレッドで C で書かれており、非常に高速に実行されます。 Apache 2.0 ライセンスに基づくオープン ソース プロジェクト。

Twemproxy は、複数の Redis インスタンスにわたる自動シャーディングをサポートし、ノードが使用できない場合のオプションのノード除外サポートをサポートします (これにより、インスタンスへのキーのマッピングが変更されるため、Redis をキャッシュとしてのみ使用する必要があります。この機能のみを使用してください)。 。

複数のプロキシを起動し、接続を受け入れる最初のプロキシにクライアントを接続させることができるため、これは単一障害点ではありません。

基本的に、Twemproxy はクライアントと Redis インスタンスの間の中間層であり、追加の複雑さを最小限に抑えながらシャードを確実に処理できるようにします。これは、Redis シャーディングを処理する現在推奨されている方法です。

7.3 コンシステント ハッシュをサポートするクライアント

Twemproxy の代わりに、クライアント側シャーディングを備えたクライアント実装を使用することもできます。 、一貫したハッシュまたは他の同様のアルゴリズムを通じて。 redis-rb や Predis など、コンシステント ハッシュをサポートする Redis クライアントがいくつかあります。

Redis クライアントの完全なリストをチェックして、プログラミング言語をサポートし、一貫性のあるハッシュを実装する成熟したクライアントがあるかどうかを確認してください。

以上がRedis シャーディング (分散キャッシュ)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。