Redis でのキャッシュの侵入、雪崩、故障

概要：

キャッシュの侵入: まったく存在しないキーに対する大量のリクエストにより、アプリケーションサーバーへの負荷が増大します。
キャッシュ雪崩: Redis 内の多数のキーがまとめて期限切れになり、データベースへの負荷が増大し、サーバーがクラッシュします。
キャッシュの内訳: Redis のホットスポットキーの有効期限が切れ (多数のユーザーがホットスポットキーにアクセスしますが、ホットスポットキーの有効期限が切れます)、データベースへのアクセス圧力が瞬時に高まります。

この 3 つが出現する根本原因: Redis のヒット率が低下する、リクエストが DB に直接ヒットする。

通常の状況では、大量のリソース要求は redis によって応答され、redis から応答が得られなかった一部の要求のみが DB を要求するため、DB への負荷は非常に小さく、正常に動作します。

解決：

1. キャッシュの侵入

キーに対応するデータが redis に存在しません。このキーに対するリクエストがキャッシュから取得されないたびに、リクエストはデータベースに転送されます。アクセス数が多い場合、データベースが超過する可能性があります。たとえば、存在しないユーザー ID を使用してユーザー情報を取得し、Redis キャッシュもデータベースも取得しない場合、ハッカーがこの脆弱性を悪用して攻撃すると、データベースが圧倒される可能性があります (ハッカーは存在しないデータにアクセスし、サーバーに多大な負荷がかかります)。

解決：

キャッシュはミスした場合に受動的に書き込まれ、フォールトトレランスのため、ストレージ層からデータが見つからない場合はキャッシュに書き込まれないため、存在してはいけないデータです。これにより、この存在しないデータが発生します。ストレージ層でのクエリがキャッシュの意味を失うたびに要求される

空の値をキャッシュする: クエリによって返されたデータが空の場合 (データが存在するかどうかに関係なく)、空の結果 (null) をキャッシュします。これにより、データベースアクセスへの負担が軽減され、有効期限が設定されます。空の結果は非常に短く、5 分以内になります。(単純な緊急解決策としてのみ)
アクセシブルリスト (ホワイトリスト) を設定する: ビットマップタイプを使用してアクセシブルリストを定義します。リスト ID はビットマップのオフセットとして使用されます。各訪問はビットマップ内の ID と比較されます。アクセス ID がビットマップ、インターセプトします。アクセスは許可されていません。
ブルームフィルター: 考えられるすべてのデータを十分な大きさのビットマップにハッシュし、存在してはいけないデータはこのビットマップによってインターセプトされるため、基盤となるストレージシステムに対するクエリのプレッシャーが回避されます。
データ検証: ユーザー権限の傍受と同様に、id=-3872 の無効なアクセスは直接傍受され、これらのリクエストは Redis と DB に到達することを許可されません。
リアルタイム監視： Redisのヒット率が急激に低下し始めていることが判明した場合、アクセスされたオブジェクトやアクセスされたデータを確認し、運用保守担当者と協力してサービスを制限するブラックリストを設定する必要があります。

予防：

Null 値をキャッシュとして使用する場合、Redis リソースが過剰に消費されるのを防ぐために、キーによって設定された有効期限が長すぎないようにする必要があります。
Null 値のキャッシュは受動的な防御方法であり、ハッカーが大量の存在しないデータを激しく要求した場合、大量の Null 値を Redis に書き込む必要があり、Redis のメモリ使用量が不足する可能性があります。
ブルームフィルターを使用すると、ユーザーがアクセスしたときにリソースが存在するかどうかを判断でき、存在しない場合はアクセスが直接拒否されます。
ブルームフィルターには特定のエラーがあるため、キャッシュ侵入の問題を解決するには、通常、インターフェイスのトラフィック制限（一定期間内のユーザーアクセスの頻度を規制する）、権限の検証、ブラックリストなどと連携する必要があります。

2. キャッシュなだれ

多数のキーに対応するデータが存在しますが、 redis で期限切れになります。現時点で多数の同時リクエストがある場合、これらのリクエストは通常、バックエンド DB からデータをロードし、それが見つかったときにキャッシュに設定し直します。キャッシュの有効期限が切れると、大量の同時リクエストがバックエンド DB を瞬時に圧倒する可能性があります。キャッシュ雪崩は、多くのキーの障害を対象としており、redis のヒットに失敗し、データベースの負荷が急増します。キャッシュの故障とは、特定の人気のあるキーが失敗し、redis のヒットに失敗し、データベースの負荷が急増することを意味します。

解決：

マルチレベルのキャッシュアーキテクチャを構築します: nginx キャッシュ + redis キャッシュ + その他のキャッシュ (ehcache など)、プログラム設計はより複雑です
ロックまたはキューを使用する: ロックまたはキューを使用して、一度に多数のスレッドがデータベースの読み取りおよび書き込みを行わないようにして、障害が発生したときに基盤となるストレージシステムに大量の同時リクエストが発生するのを回避します。。効率が低いため、同時実行性が高い状況には適していません
キャッシュを更新するために有効期限フラグを設定します。キャッシュデータが期限切れかどうかを記録し (事前量を設定)、期限切れの場合は、バックグラウンドで実際のキーキャッシュを更新するように別のスレッドに通知するようにトリガーされます。
キャッシュフラグを設定します。キャッシュされたデータが期限切れかどうかを記録します。期限切れの場合は、バックグラウンドで実際のキーを更新するように別のスレッドに通知するようにトリガーされます。
有効期限を分散する: 自動乱数生成を使用することで、キーの有効期限がランダム化され、一括有効期限が切れるのを防ぎます。

3. キャッシュの内訳:

キャッシュ雪崩の理由: Redis のホットキーの有効期限が切れていますが、現時点では期限切れのキーにアクセスしているユーザーが多数います。

Redis は正常に実行されており、大量の有効期限はありません (有効期限を過ぎるとアクセスできなくなり、失効した場合はデータベースにアクセスする必要があります)
データベースへのアクセス圧力が瞬時に高まります

解決：

事前にホットデータを設定する: Redis へのアクセスがピークになる前に、事前に一部のホットデータを Redis に保存し、これらのホットデータキーの期間を長くします。
データを監視してタイムリーに調整する: サイトでどのデータが人気があるかを監視し、キーの有効期限をリアルタイムで調整します。
ロックメカニズム: 1 つのリクエストのみがミューテックスを取得し、DB 内のデータをクエリして Redis に返すことができます。その後、すべてのリクエストが Redis から応答を取得できます。