Redisの基礎知識(3):キャッシュペネトレーション、キャッシュブレークダウン、キャッシュアバランチ


 私たちは、大量のデータの影響に対処するためにプロジェクトで Redis を広範囲に使用していますが、使用プロセス中に、キャッシュの破壊、キャッシュの侵入、キャッシュなだれなどの特殊な状況にも遭遇します。

1. キャッシュの侵入

キャッシュペネトレーションとは、存在してはいけないデータをクエリすることを指します。キャッシュがミスした場合はデータベースからキャッシュをクエリする必要があるため、データが見つからない場合はキャッシュに書き込まれません。これにより、存在しないデータが発生します。クエリが要求されるたびにデータベースにアクセスするため、データベースに負荷がかかります。
つまり、キャッシュにデータがなく、データベースにもデータがありません。

出現過程

クライアントが 1 秒あたり 5,000 リクエストを送信すると、データベース内で見つからなかったとしても、そのうち 4,000 リクエストはハッカーによる悪意のある攻撃です。たとえば、ユーザー ID が正の数で、ハッカーが作成したユーザー ID が負の数である場合、ハッカーが 1 秒あたり 4,000 件のリクエストを送信し続けると、キャッシュは機能せず、データベースはすぐに強制終了されます。

ここに画像の説明を挿入

解決

リクエストパラメータを確認し、不当であれば直接リターンします。
クエリできないデータもキャッシュに置かれ、値は空になります。たとえば、set -999 は
ブルームフィルタを使用して、キーが存在するかどうかを迅速に判断します。データベースが存在しない場合は、直接戻ります

1 つ目は最も基本的な戦略で、2 つ目は実際にはあまり使用されず、3 つ目はより一般的に使用されます。

2番目が一般的に使用されないのはなぜですか?

ハッカーが作成したリクエスト ID が乱数の場合、2 番目の方法は機能せず、代わりに、キャッシュ クリア戦略 (最近アクセスされていないキャッシュをクリアするなど) により、有用なキャッシュがクリアされます。

2. キャッシュの内訳

キャッシュブレークダウンとは、リクエストパラメータが到着すると、キャッシュ内のデータが即座に期限切れになることを意味しますが、このときの同時実行量が多く、すべてのリクエストが同時にデータベースへのリクエストに直接変換されるため、瞬時に大きな負荷がかかります。データベース上で。
つまり、キャッシュにデータはなく、データベースにデータがあり、キーが集中しています。

出現過程

有効期限が設定されたキーは高い同時実行性を持ち、一種のホット データです。キーの有効期限が切れてから、データが MySQL から再ロードされてキャッシュに配置されるまでの期間、大量のリクエストによりデータベースが強制終了される可能性があります。キャッシュなだれは多数のキャッシュ障害を指し、キャッシュの故障はホット データのキャッシュ障害を指します。

解決

キーを無期限に設定するか、有効期限が近づいたら、別の非同期スレッドを通じてキーをリセットします。
キャッシュから取得したデータが null の場合、データベースからデータを再ロードするプロセスはロックされます。分散ロックのデモを作成します。以下の実装

3. キャッシュ雪崩

キャッシュなだれとは、キャッシュ内の多数のデータが同時に有効期限切れになることを指します。
つまり、キャッシュにはデータがなく、データベースにはデータがあり、キーは分散しています。

キャッシュ ブレークダウンとは異なり、キャッシュ ブレークダウンは同じデータに対して同時にクエリを実行することを指します。キャッシュ アバランシェは、別のデータの有効期限が切れて多くのデータが見つからないため、データベースがチェックされることを意味します。

出現過程

次のようなシステムがあるとします。ピーク期間のリクエストは 1 秒あたり 5000 回、4000 回はキャッシュに送られ、データベースにかかるのは 1000 回だけです。1 秒あたり 1000 回のデータベース同時実行は正常な指標であり、正常に動作します。ただし、キャッシュがダウンしている場合、マシンがクラッシュするか、キャッシュが同じ有効期限を設定し、同時にキャッシュが失敗します。1 秒あたり 5,000 のリクエストはすべてデータベースに送信され、データベースはすぐに停止します。データベースは 1 秒あたり最大 2,000 のリクエストに耐えることができます。DBA がデータベースを再起動すると、データベースは新しいリクエストによって即座に強制終了されます。これはキャッシュ雪崩です。
ここに画像の説明を挿入

解決

事前: 全体的なクラッシュを回避するために、redis 高可用性、マスター/スレーブ + センチネル、redis クラスター
イベント時: MySQL が強制終了されることを回避するために、ローカル ehcache キャッシュ + hystrix の電流制限とダウングレード その後
: redis 永続 RDB+AOF、高速リカバリキャッシュ データ
キャッシュ 同時障害を避けるため、有効期限はランダムな値に設定されます

おすすめ

転載: blog.csdn.net/weixin_44816664/article/details/132689192