Redis の雪崩の原因とその解決方法

1. はじめに

ご存知のとおり、コンピュータのボトルネックの 1 つは IO です。メモリとディスク速度の不一致の問題を解決するために、キャッシュが生成され、ホット データがメモリに格納されます。いつでも使用できるメモリを自由に確保して、データベースへのリクエスト接続を減らし、データベースのハングを防ぎます。故障であっても、後述するペネトレーションとアバランシェであっても、キャッシュ内の特定のホット キーが失敗した場合など、すべては高い同時実行性を前提としていることに注意してください。

2. 問題の原因

主な理由は 2 つあります:

• 1. キーの有効期限が切れています。

• 2. ページ置換によりキーが削除されます。

最初の理由として、Redis ではキーに有効期限があり、キーの有効期限が特定の時点 (モールが活動を行っている場合は、0 時から) になると、その後、0 時を過ぎると、特定のキーの有効期限が切れ、すべての製品クエリ リクエストがデータベースに押し付けられ、データベースが崩壊します。

2 番目の理由は、メモリが限られているため、新しいデータを常にキャッシュし、古いデータを削除する必要があるため、特定のページ置換戦略 (一般的なページ置換アルゴリズムの図) では、データイベント前に特定の製品に誰も関心がなければ、それらは確実に排除されます。

3. 故障時の処理アイデア

通常の処理リクエストは図のとおりです:

キーの有効期限が切れているため、 Redis にトラフィックが流入すると、Redis のシングルスレッド特性により、タスクがキュー内で順番に実行されると考えられます。リクエストが Redis に到達し、キーの有効期限が切れていることが判明すると、次の操作が実行されます。ロックを設定します。

処理は大まかに次のとおりです:

• リクエストが Redis に到達し、Redis キーの有効期限が切れていることがわかります。ロックがあるかどうかを確認します。ロックがありません。キューの最後尾に戻ります。

• ロックを設定します。他のスレッドがロックを設定している可能性があるため、これは set() ではなく setnx() であることに注意してください。 .

• ロックの取得、取得 ロックに到達したら、データベースに移動してデータを取得し、リクエストが返された後にロックを解放します。

# しかし、新たな疑問が生じます。ロックを取得した後にデータを取得するリクエストがハングしたらどうなるでしょうか?つまり、ロックは確立されていません。解放されました。他のプロセスがロックを待っています。解決策は次のとおりです:

ロックの有効期限を設定します。有効期限に達しても解放されていない場合は、自動的に解放されます。問題は再び発生します。ロックがかかっていると言うのは簡単ですが、ロックの場合はタイムアウトはどうでしょうか?つまり、設定した時間内にデータが取得されず、ロックが期限切れになります。一般的な考え方は、ロックの有効期限の値です。増加しますが、最初のリクエストがタイムアウトになる可能性があるため、信頼性が低くなります。後続のリクエストもタイムアウトになる場合があります。タイムアウトが連続して複数回発生すると、ロックの有効期限値は非常に大きくなるはずです。これには欠点が多すぎます。

別のアイデアは、別のスレッドを開始して監視することです。データをフェッチしているスレッドがハングアップしない場合は、ロックの有効期限を適切に遅らせます。

4. 侵入

侵入の主な理由は、多くのリクエストがデータベースに存在しないデータにアクセスしていることです。本がリクエストされました。お茶製品をクエリするには、Redis キャッシュは主にホット データのキャッシュに使用されるため、データベースに存在しないデータはキャッシュできません。この異常なトラフィックはデータベースに直接到達し、「なし」のクエリ結果を返します。

この種のリクエストに対処するための解決策は、ブルーム フィルター、拡張ブルーム フィルター、カッコー フィルターなどのフィルター層をアクセス リクエストに追加することです。

ブルーム フィルターに加えて、いくつかのパラメーター チェックを追加できます。たとえば、データベース データ ID は一般に増加しています。id = -10 などのパラメーターをリクエストした場合、この状況を回避するために、Redis はユーザーの信頼性検証などの操作を実行できます。

5. アバランチ

アバランチはブレークダウンに似ていますが、ブレークダウンは特定の瞬間にホットスポット キーが失敗することを意味するのに対し、アバランチは大量のホットスポット キーが一時的に失敗することを意味する点が異なります。インスタントです。ネットワーク上には多数のホットスポット キーがあります。ブログでは、雪崩を解決する戦略は有効期限をランダム化することであると強調しています。これは非常に不正確です。たとえば、銀行が活動を行う場合、以前は金利係数は 2% でしたが、しかし、ゼロ点の後、係数は 3% に変更されます。この状況により、ユーザーの金利が変化する可能性があります。対応するキーはランダムに期限切れになるように変更されますか?過去のデータを使用する場合、それをダーティデータと呼びます。

明らかに不可能ですが、お金を節約することもできます f0c;あなたは年末までの利息で 300 万を節約できますが、隣の家には 200 万しかありません。これは喧嘩ではありません、冗談です~

正しい考え方は、まずキーの有効期限が時間に関係しているかどうかを確認する必要があるということです。時間に関係がない場合は、ランダムな有効期限で解決できます。 ###

それが時点に関連する場合、たとえば、先ほど述べた銀行がある日に特定の係数を変更する場合、強力な依存関係の内訳ソリューションを使用する必要があります。その戦略は、最初にすべてのキーを過去のスレッドで更新することです。

バックグラウンドでホットスポット キーを更新している間、ビジネス層は、後続のリクエストへの圧力を分散するために、数ミリ秒または数秒間短時間スリープするなど、受信リクエストを遅延させます。ホットスポット キーの更新。

以上がRedis の雪崩の原因とその解決方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。