インタビュアー: Redis データのスキュー、ホットスポット、その他の問題を解決する方法

Redis は主流のテクノロジーとして多くの適用シナリオがあり、大規模、中規模、小規模の工場への多くのインタビューで主要な検査内容として挙げられています

A数日前、プラネット・スモールとのインタビューがありました。パートナーと一緒に勉強していたときに、次のような疑問に遭遇し、ブラザー・トムに相談に来ました。

これらの問題は比較的高いと考えます-頻度が高く、仕事でよく遭遇する問題なので、体系的に説明する記事を書きます

問題の説明:

あなたへの質問: Redis をレビューするときに、いくつか質問があります。ご覧ください:

Redis クラスターにデータの偏りがあり、データの分散が不均一である場合、それを解決するにはどうすればよいですか?

ホットキーを処理するときは、k-​​1、k-2... などのキーのコピーを複数作成します。 これらのコピーを均等に書き込むにはどうすればよいでしょうか?均等にアクセスするにはどうすればよいですか？

Redis はハッシュ スロットを使用してクラスターを維持します。一貫性のあるハッシュと同様に、完全な移行を回避できます。なぜ整合性のあるハッシュを使用しないのでしょうか?

返信:

パフォーマンス アクセラレータとして、分散キャッシュはシステムの最適化において非常に重要な役割を果たします。のキャラクター。ローカル キャッシュと比較すると、ネットワーク送信が追加され、所要時間は 1 ミリ秒未満ですが、集中管理という利点があり、非常に大容量のストレージ容量をサポートします。

分散キャッシュの分野では、Redis が現在広く使用されています。このフレームワークは純粋なメモリ ストレージ、コマンドのシングル スレッド実行、豊富な基礎データ構造であり、複数の次元をサポートしています。データの保存と取得。

もちろん、大量のデータを使用すると、データの偏り、データのホットスポットなど、さまざまな問題が発生します。

データ スキューとは何ですか?

単一マシンのハードウェア構成には上限があります。通常、分散アーキテクチャを使用して複数のマシンのクラスタを形成します。下の図は 3 つで構成されており、1 つの Redis マシンで構成されています。クライアントは、特定のルーティング戦略を通じて、読み取りおよび書き込みリクエストを特定のインスタンスに転送します。

ビジネス データの特殊性により、指定されたシャーディング ルールに従って、データが異なるインスタンスに不均等に分散され、大量のデータが 1 つまたは複数のマシン ノードに集中する可能性があります。これにより、他のノードがアイドル状態で待機している間にこれらのノードの負荷が大きくなり、全体的な効率が低くなります。

データの偏りの理由は何ですか?

1. 大きなキーがあります

たとえば、1 つ以上のキーを保存します。文字列型の bigKey データは多くのメモリを消費します。

ブラザー トムは以前にこの問題を調査したことがあります。開発中のトラブルを避けるために、同僚は JSON 形式を使用して複数のビジネス データを 1 つの値にマージし、1 つのキーのみを関連付けました。このキーと値のペアの容量は数百 M に達します。

大きなキーの読み取りと書き込みを頻繁に行うと、大量のメモリ リソースが消費され、ネットワーク送信に大きな圧力がかかり、その結果、リクエストの応答が遅くなり、雪崩現象が引き起こされます。 、システム A のタイムアウト アラーム。

#解決策:

方法は非常に簡単です。## を使用してください。 #分割する<span style="font-size: 16px;"></span>bigKey を複数の小さなキーに分割し、それらを個別に維持する戦略により、コストが大幅に削減されます。もちろん、この分解でもいくつかの原則に注目しており、ビジネス シナリオとアクセス シナリオの両方を考慮し、それらを緊密に統合する必要があります。

例: Redis に内部依存する RPC インターフェイスがあります。以前は、一度アクセスするだけですべてのデータを取得できました。分割すると、データのサイズが制御されます。単一の値とアクセス数 結局のところ、呼び出し数が増加すると、インターフェイス全体の応答時間が増加します。

浙江省の政府機関はプロセスの最適化を提唱しており、プロセスを最大 1 回実行することも同じ原則です。

#2. ハッシュタグの不適切な使用

Redis は単一のスレッドを使用してコマンドを実行するため、原子性が確保されます。クラスターのデプロイメントが採用される場合、mset スクリプトや lua スクリプトなどの複数キーのバッチ操作を解決し、異なるキーを同じ Redis インスタンスに確実にルーティングできるようにするために、

HashTag メカニズムが導入されます。

使用法も非常に簡単です。

{}<span style="font-size: 16px;"></span> 中括弧を使用し、キーを指定してその中の文字列のみを計算します。ハッシュを中括弧で囲むことにより、異なるキーのキーと値のペアが同じハッシュ スロットに挿入されます。

例:

192.168.0.1:6380> CLUSTER KEYSLOT testtag
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT {testtag}
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT mykey1{testtag}
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT mykey2{testtag}
(integer) 764

ビジネス コードを確認し、HashTag が導入されているかどうかを確認します。 . 、1 つのインスタンスにルーティングされているキーが多すぎます。特定のシナリオに基づいて分割方法を検討します。

RocketMQ と同様に、多くの場合、パーティションが適切に保たれていれば、ビジネス ニーズを満たすことができます。実際には、問題を解決するために問題を解決するのではなく、このバランス ポイントを見つける必要があります。

3. スロットの不均一な分散

Redis クラスターのデプロイ方法が採用される場合、クラスター内のデータベースは 16384 個のスロットに分割されます (スロット)、データベース内の各キーはこれら 16384 個のスロットの 1 つに属し、クラスター内の各ノードは 0 個または最大 16384 個のスロットを処理できます。

比較的大きなスロットを少しアイドル状態のマシンに手動で移行して、ストレージとアクセスの均一性を確保できます。

#キャッシュ ホットスポットとは何ですか?

キャッシュ ホットスポットとは、ほとんどまたはすべてのビジネス リクエストが同じキャッシュ データにヒットすることを意味します。これにより、キャッシュ サーバーに多大な負荷がかかり、単一サーバーの容量を超えることもあります。負荷制限を超えているため、サーバーのダウンタイムが発生します。 ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃解決：＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ ＃ 1. 複数のコピーをコピーします

#key#01、key#02 など、キーの後に連続番号を入力できます。 。 。キー#10 の複数のコピー。これらの処理されたキーは複数のキャッシュ ノードに配置されます。

クライアントがアクセスするたびに必要なのは、元のキーに基づいて乱数をシャード数の上限と結合し、リクエストをインスタンス ノードにルーティングすることだけです。ルーティングできません。 注: キャッシュは通常、有効期限を設定します。一元的なキャッシュの失敗を避けるために、キャッシュの有効期限が同じにならないようにします。プリセットに基づいて乱数を追加できます。

データ ルーティングの均一性については、ハッシュ アルゴリズムによって保証されます。

#2. ローカル メモリ キャッシュ

ホットスポット データをクライアントのローカル メモリにキャッシュし、有効期限を設定します。読み取りリクエストごとに、まずローカル キャッシュにデータが存在するかどうかを確認し、存在する場合は直接返し、存在しない場合は分散キャッシュ サーバーにアクセスします。

ローカル メモリ キャッシュはキャッシュ サーバーを完全に「解放」し、キャッシュ サーバーに負担をかけません。

欠点: キャッシュされた最新のデータをリアルタイムに感知するのは少し面倒で、データの不整合が発生する可能性があります。有効期限を比較的短く設定し、パッシブ更新を使用できます。もちろん、監視メカニズムを使用して、データの変更が検出された場合にローカル キャッシュを適時に更新することもできます。

#Redis クラスター一貫性のあるハッシュを使用しないのはなぜですか?

Redis クラスターには 16384 個のハッシュ スロットがあり、それぞれにkey<span style="font-size: 16px;"></span> 検証後、CRC16<span style="font-size: 16px;"></span> が合格します。 ##16384<span style="font-size: 16px;">型を取り、どのスロットを配置するかを決定します。クラスター内の各ノードは、ハッシュ スロットの一部を担当します。たとえば、現在のクラスターに 3 つのノードがある場合、</span>node-1<span style="font-size: 16px;"> には数字が含まれます0 ～ 5460。ハッシュ スロット、</span>node-2<span style="font-size: 16px;"> ハッシュ スロット 5461 ～ 10922、</span>node-3 が含まれます。 <span style="font-size: 16px;">ハッシュ スロット 10922 ～ 16383 が含まれます。 </span>

コンシステント ハッシュ アルゴリズムは、1997 年に MIT の Karger らによって提案されました。分散キャッシュの問題を解決するために。

コンシステント ハッシュ アルゴリズムは、本質的にはモジュロ アルゴリズムです。サーバーの数に基づいてモジュロを取得するのとは異なり、コンシステント ハッシュは固定値 2^32 をモジュロとします。

Formula = hash (key) % 2^32

モジュラスの結果は次のようになります。範囲 [0, 2^32-1] の整数、

円上のマップされた位置から時計回りに見つかった最初のノードが、キーが保存されているノードです # ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

一貫性のあるハッシュ アルゴリズムは、拡張または縮小によって引き起こされるキャッシュ障害の問題を大幅に軽減し、このノードが担当するキーの小さなセクションにのみ影響します。クラスター内のマシンの数が少なく、単一マシンの負荷レベルが通常非常に高い場合、特定のノードのダウンタイムによって引き起こされる圧力により、雪崩現象が簡単に引き起こされる可能性があります。

##例:

Redis には次のものがあります。クラスタには合計 4 台のマシンが含まれます。データが均等に分散されていると仮定すると、各マシンはトラフィックの 4 分の 1 を負担することになります。マシンが突然ハングアップすると、時計回りに次のマシンがトラフィックの追加の 4 分の 1 を負担することになります。 、トラフィックの半分を負担することになるのはまだ少し怖いです。

しかし、CRC16<span style="font-size: 16px;"></span> が計算され、スロットとインスタンスの間のバインディング関係と結合される場合、拡張または縮小する場合、キャッシュ障害を引き起こすことなく、対応するノードのキーのデータをスムーズに移行し、新しいスロット マッピング関係をブロードキャストして保存するだけで済み、柔軟性は非常に高くなります。

さらに、サーバー ノードの構成に違いがある場合、異なるノードに割り当てられるスロット番号をカスタマイズし、異なるノードの負荷能力を調整できるため、非常に便利です。

以上がインタビュアー: Redis データのスキュー、ホットスポット、その他の問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。