Redis のホット キーの問題に対処するにはどうすればよいですか?次の記事では、Redis キャッシュ ホット キーの問題に対する一般的な解決策を紹介します。
C サイドのビジネスを行う場合、データベースへの負担を軽減し、ビジネスの応答時間を短縮するために、一次キャッシュを導入することは避けられません。問題を解決するためにミドルウェアが導入されるたびに、同時に、前の記事「データベースとキャッシュの一貫性の実際」で述べたキャッシュの一貫性を実現する方法など、注意を必要とする多くの新たな問題も必然的に生じます。実際、Redis を 1 次キャッシュとして使用するときに、ホット キーや大きなキーなど、他にも問題が発生する可能性があります。この記事では、ホット キー(ホット キー)について説明します。 ) 問題と、ホット キー 問題を合理的に解決する方法。
ホットキー問題は何ですか?またその原因は何ですか?
一般的に、私たちが使用するキャッシュ Redis はマルチノード クラスター バージョンであり、特定のキーを読み書きする場合、対応するスロットはキーのハッシュに基づいて計算され、それに基づいて見つけることができます。対応するシャード (1 つのマスターと複数のスレーブで構成される Redis クラスターのセット) は、K-V にアクセスするために使用されます。しかし、実際の申請プロセスでは、特定の事業や特定の期間（電子商取引事業における商品の速報販売活動など）において、同じキーへのアクセス要求が大量に発生することがあります。すべてのリクエスト (およびそのようなリクエストの読み取り/書き込み比率が非常に高い) は同じ Redis サーバーに分類されるため、Redis の負荷が大幅に増加します。この時点で、システム全体に新しい Redis インスタンスを追加すると、ハッシュ アルゴリズムによれば、同じキーに対するリクエストは引き続き同じ新しいマシンに送信されるため、役に立ちません。これが依然としてシステムのボトルネックとなり 2、さらにはクラスター全体のクラッシュを引き起こす可能性があります。このホットスポット キーの値が相対的な場合は、この問題は「ホット キー」問題として知られています。 [関連する推奨事項: Redis ビデオ チュートリアル ]
以下の図 1 と図 2 に示すように、これらはそれぞれ通常の Redis クラスター クラスターとプロキシ プロキシのレイヤーを使用した Redis クラスター キー アクセスです。
上で述べたように、ホット キーはクラスター内の少数のノードに非常に高い負荷圧力をもたらします。場合、これらのノードがダウンする可能性があり、キャッシュ クラスター全体の動作に影響を与えるため、ホット キーを発見し、ホット キーの問題を時間内に解決する必要があります。
ホット キーの検出は、Redis クラスターとホット キーの分散によって引き起こされる重大な影響を考慮して、大まかで細かい思考プロセスを通じて実行できます。ホットスポットキー検出用。
ホット キーの最も明白な影響は、Redis クラスター全体の QPS が維持されているという前提でのトラフィック分散です。クラスタ内のスロットが不均一であるという問題に関しては、最初に考えられるのは、各スロットのトラフィックを監視することです。レポート後、各スロットのトラフィックを比較すると、特定のスロットを見つけることができます。ホットキーが表示されたときに影響を受けます。この監視は最も便利ですが、粒度が粗すぎるため、初期のクラスター監視ソリューションにのみ適しており、ホット キーが正確に検出されるシナリオには適していません。
図 2 で Redis クラスター プロキシ モードを使用している場合、すべてのリクエストが送信されるため、最初にプロキシへ 特定のスロット ノードに移動すると、このホット キーの検出統計がプロキシで実行されます。プロキシでは、タイム スライディング ウィンドウに基づいて各キーがカウントされ、その後対応するしきい値を超えた数がカウントされます。冗長な統計が多すぎるのを防ぐために、プレフィックスとタイプに対応するキーのみをカウントするようにいくつかのルールを設定することもできます。この方法には少なくともプロキシ メカニズムが必要であり、Redis アーキテクチャの要件もあります。
redis 4.0 以降のバージョンは、各ノードで LFU ベースのホットスポット キー検出メカニズムをサポートしています。 を使用します。 redis-cli –hotkeys redis-cli の実行時に –hotkeys オプションを追加するだけです。このコマンドをノード上で定期的に使用して、対応するホットスポット キーを検出できます。
以下に示すように、redis-cli –hotkeys の実行結果とホットキーの統計が確認できます。は、統計を収集するためにスケジュールされた実行を設定できます。
クライアントからは毎回 redis コマンドが発行されるので、これを元に Redis クライアントの一部のコードで統計や集計を行うことができます。各クライアントはタイム スライディング ウィンドウに基づいて統計を作成し、特定のしきい値を超えると統計がサーバーに報告され、サーバーは統計を各クライアントに一律に送信し、対応する有効期限を設定します。
この方法はより 美しい ように見えますが、実際には、クライアント側での変換が実行中のプロセスに大きな影響を与えるため、一部のアプリケーション シナリオにはあまり適していません。メモリ オーバーヘッド、より直接的に言えば、Java や goLang などの自動メモリ管理言語では、オブジェクトがより頻繁に作成されるため、gc がトリガーされ、インターフェイスの応答時間が増加します。これは簡単に予測できません。
最終的には、各企業のインフラストラクチャを通じて対応する選択を行うことができます。
上記の方法により、対応するホット キーまたはホット スロットが検出されたため、対応するホット キーの問題を解決する必要があります。ホット キーを解決するにはいくつかのアイデアがありますので、1 つずつ見てみましょう。
最も単純かつ大雑把な方法は、特定のスロットまたはホット キーの電流を制限することです。これはビジネス上の損失であるため、オンラインで問題が発生し、損失を停止する必要がある場合にのみ、特定の電流制限を使用することをお勧めします。
ローカル キャッシュは、最も一般的に使用されるソリューションでもあります。第 1 レベルのキャッシュはそのような大きな負荷に耐えることができないためです。 , 2次キャッシュを追加するだけです。各リクエストはサービスによって発行されるため、この 2 次キャッシュをサービス側に追加するのが最適です。そのため、サーバーは対応するホット キーを取得するたびに、ローカル キャッシュを使用してコピーを保存し、ローカル キャッシュが保存されるまでコピーを保存できます。その後、redis クラスターへの負荷を軽減するよう再度リクエストします。 Java を例に挙げると、guavaCache は既製のツールです。次の例:
//本地缓存初始化以及构造
private static LoadingCache<String, List<Object>> configCache
= CacheBuilder.newBuilder()
.concurrencyLevel(8) //并发读写的级别，建议设置cpu核数
.expireAfterWrite(10, TimeUnit.SECONDS) //写入数据后多久过期
.initialCapacity(10) //初始化cache的容器大小
.maximumSize(10)//cache的容器最大
.recordStats()
// build方法中可以指定CacheLoader，在缓存不存在时通过CacheLoader的实现自动加载缓存
.build(new CacheLoader<String, List<Object>>() {
@Override
public List<Object> load(String hotKey) throws Exception {
}
});
//本地缓存获取
Object result = configCache.get(key);ローカル キャッシュが私たちに与える最大の影響は、データの不整合の問題です。キャッシュの有効期限をどのくらい長く設定するかによって、最も長いオンライン データの不整合の問題が発生します。このキャッシュ時間は、次のようにする必要があります。独自のクラスター圧力と、ビジネスで許容される最大不整合時間を測定します。
データの一貫性を可能な限り確保しながら、ホット キーの問題が発生しないようにするにはどうすればよいでしょうか?キーを削除することも良い解決策です。
キャッシュに入れるとき、対応するビジネスのキャッシュ キーを複数の異なるキーに分割します。以下の図に示すように、まず更新キャッシュ側でキーを N 個の部分に分割します。たとえば、キーの名前が「good_100」の場合、「good_100_copy1」、「good_100_copy2」の 4 つの部分に分割できます。 「、「good_100_copy3」、「good_100_copy4」、これらの N キーは、更新または追加されるたびに変更する必要があります。この手順は、キーを削除することです。
サービス側では、アクセスするトラフィックを十分に均一にする方法と、アクセスしようとしているホットキーにサフィックスを追加する方法を見つける必要があります。マシンの IP アドレスまたは MAC アドレスに基づいてハッシュを実行し、値の残りと分割キーの数を取得し、最終的にどの種類のキー サフィックスに結合するかを決定する方法はいくつかあります。どのマシンにヒットするかについては、サービス開始時に 1 つ、乱数は分割キーの数の残りです。
マイクロサービス構成センターに詳しい人のために、アイデアは、構成センターの一貫性に合わせて変更できます。 nacos を例に挙げると、分散構成の一貫性をどのように実現し、迅速に対応できるのでしょうか?次に、キャッシュを構成に例えて、次のように実行します。
ロングポーリング ローカリゼーション構成。まず、サービスの開始時にすべての構成が初期化され、その後、現在のサービス監視構成が変更されたかどうかを確認するために定期的にロング ポーリングが開始されます。変更がある場合は、ロング ポーリング リクエストがすぐに返され、ローカル構成が更新されます。変更がない場合は、すべてのビジネス コードでローカル メモリ キャッシュ構成が使用されます。これにより、分散キャッシュ構成の適時性と一貫性が保証されます。
上記の各ソリューションは、ホット キーの問題を解決するために比較的独立しているため、実際にビジネス上の要求に直面した場合、実際には全体的なスキーム設計を検討するには長い時間がかかります。一部の極端なフラッシュ セールス シナリオによって引き起こされるホットキーの問題については、十分な予算があれば、サービス ビジネスと Redis キャッシュ クラスターを直接分離して、通常のビジネスへの影響を回避することができます。同時に、一時的により優れた災害復旧と、電流制限措置。
現在、市場にはホットキー用の比較的完全なアプリケーション レベルのソリューションが多数あり、その中には、JD.com がこの点に関するオープン ソースのホットキー ツールを用意しています。原理は、クライアント側で洞察を作成し、対応するホットキーを報告することです。サーバーがそれを検出すると、対応するホットキーを対応するサーバーに送信してローカル キャッシュを行い、このローカル キャッシュはリモートの対応付け後に同期的に更新されます。キーは更新されています。すでにこれは、現在比較的成熟した 自動ホット キー検出および分散整合性キャッシュ ソリューション、京東小売ホット キー です。
上記は、作成者が大まかに理解している、または実践したホット キーの対処方法に関するいくつかの解決策です。ホット キーの発見から ホット キーの 2 つの重要な問題を解決します。各ソリューションには、ビジネスの不一致や導入の難しさなど、長所と短所があります。自社のビジネスの現在の特性や会社の現在のインフラストラクチャに基づいて、対応する調整や変更を行うことができます。
プログラミング関連の知識について詳しくは、プログラミング入門をご覧ください。 ！
以上がRedis のキャッシュ ホット キーの問題に対処する方法について話しましょう?よく使用されるソリューションの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
