インタビュアー: Redis データのスキュー、ホットスポット、その他の問題を解決する方法-＆＃＆面接の質問-php.cn

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

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

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

問題の説明:

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

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

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

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

返信:

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

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

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

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

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

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

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

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

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

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

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

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

#解決策:

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

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

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

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

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

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

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

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

{} 中括弧を使用し、キーを指定してその中の文字列のみを計算します。ハッシュを中括弧で囲むことにより、異なるキーのキーと値のペアが同じハッシュスロットに挿入されます。

例:

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 の複数のコピー。これらの処理されたキーは複数のキャッシュノードに配置されます。

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