Redis キャッシュ雪崩、キャッシュのブレークダウン、キャッシュの侵入を 1 つの記事で理解する

この記事では、Redis に関する関連知識を提供し、主にキャッシュ アバランチ、キャッシュ ブレークダウン、キャッシュ ペネトレーションに関する関連コンテンツを紹介します。一緒に見ていきましょう。お役に立てば幸いです。 . 皆さん助かります。

推奨される学習: Redis ビデオ チュートリアル

Redis の高頻度の問題、キャッシュ雪崩、キャッシュのブレークダウン、およびキャッシュの侵入について面接などで似たような質問をされたことは誰でもあると思います。なぜこれらの質問がこれほど人気が​​あるのでしょうか? Redis キャッシュを使用すると、これらの問題が発生しやすくなるからです。次に、これらの問題がどのように発生するのか、そしてそれに対応する解決策は何なのかを見てみましょう。

キャッシュなだれ

まず、キャッシュなだれについて見てみましょう。キャッシュなだれの概念は次のとおりです: 大量のリクエストが Redis キャッシュ内で処理されず、リクエストのフラッディングが発生します。データベースへの負荷が大幅に増加します。

キャッシュ アバランシェが発生する理由は次の 2 つに要約できます。

• キャッシュ内には同時に期限切れになる大量のデータがあるため、大量のデータがキャッシュに保存されます。現時点で、のリクエストがデータベースに送信されます。
• Redis キャッシュ インスタンスに障害が発生し、大量のリクエストを処理できなくなり、リクエストがデータベースに送られることになります。

最初のシナリオを見てみましょう。キャッシュ内の大量のデータが同時に期限切れになります。

キャッシュ内の大量のデータが同時に期限切れになる

凡例と組み合わせると、大量のデータが同時に期限切れになり、その後、多数のリクエストが発生することを意味します。この時点でデータを読み取ります。当然、キャッシュ雪崩が発生し、データベースの負荷が大幅に増加します。

大量のデータが同時に期限切れになる場合の解決策

大量のデータが同時に期限切れになる問題に対処するには

• データの有効期限設定にランダムな時間を追加します。つまり、expired コマンドを使用してデータの有効期限を設定するときに、ランダムな時間を追加します。たとえば、データ a の有効期限は 5 分で、その 5 分に 10 ～ 120 秒がランダムに追加されます。これにより、大量のデータが同時に期限切れになるのを防ぎます。
• サービスの低下: つまり、キャッシュ雪崩が発生した場合、(1) アクセスがコア データではない場合、キャッシュ ヒットがない場合、データベースはデータベースにアクセスせず、事前設定された情報など情報; (2) コアデータにアクセスしてキャッシュがミスした場合、データベースクエリは許可されます。このようにして、コア データではないすべてのリクエストは拒否され、データベースに送信されます。

#大量のデータが同時に期限切れになる状況を確認した後、Redis キャッシュ インスタンスに障害が発生する状況を見てみましょう。

Redis キャッシュ インスタンスの障害によるキャッシュ雪崩

この場合、Redis は読み取りリクエストを処理できず、リクエストは当然データベースに送信されます。

一般的に、この状況に対処する方法は 2 つあります。

• ビジネス システムで サービス サーキット ブレーカー/リクエスト電流制限 を適切に実行する。
• 事前の注意事項: マスター/スレーブクラスター切り替えなど、Redis の高信頼クラスターを構築してください。

サービス サーキット ブレーカーとは、Redis に障害が発生した場合に、キャッシュ システムへのアクセス要求が一時停止されることを意味します。 Redis が通常の状態に戻るまで待ってから、アクセス要求をオープンします。

このようにして、MySQL の負荷圧力、Redis の CPU 使用率、メモリ使用量、QPS など、Redis またはデータベースの実行ステータスを監視する必要があります。 Redis インスタンスのキャッシュが崩壊したことが判明した場合、サービスは一時停止されます。

この状況では、事実上、大量のリクエストが発行され、データベースに負荷がかかる可能性があります。ただし、アクセス要求は停止され、ビジネスエンドに大きな影響を与えます。

したがって、ビジネスエンドへの影響を軽減するために、リクエスト電流制限メソッドを使用して QPS を制御し、データベースへのリクエストが多すぎることを回避できます。たとえば、以下の図では 1 秒あたり 20,000 リクエストがありますが、Redis の障害によりダウンしていました。電流制限操作により qps が 1 秒あたり 2,000 に減少しましたが、データベースは依然として 2,000 qps を問題なく処理できました。

キャッシュ ブレークダウン

キャッシュ ブレークダウンとは、頻繁にアクセスされる個々のホットスポット データをキャッシュできず、リクエストがデータベースに流し込まれることを意味します。多くの場合、ホットスポット データの有効期限が切れたときに発生します。

キャッシュ破綻問題については、アクセス頻度の高いホットデータであることが分かっているため、処理方法が単純かつ粗雑であり、有効期限も設定されていません直接。ホットスポット データへのアクセスが頻繁になくなるまで待ってから、手動で処理してください。

快取穿透

快取雪崩有些特別，它是指要存取的資料既不在Redis緩存，也不在資料庫中。當大量請求進到系統時，Redis和資料庫都會有巨大壓力。

導致快取穿透的原因通常有2種：

• #資料被誤刪除了，導致快取和資料庫都沒有資料了。然而客戶端是不知道的，還在瘋狂請求。
• 有惡意攻擊的情況：也就是被人盯上了，專門去查沒有的資料。

對於快取穿透的情況，解決方案可以參考下面幾種：

• 是對快取設定空值或預設值。 例如發生快取穿透時，在Redis快取中設定空值/預設值。後續查詢該值時就直接回傳這個預設值了。
• 使用布隆篩選器來判斷資料是否存在，避免從資料庫查詢。
• 在前端就進行請求偵測。 例如在前端將一些不合法的請求直接過濾，不要發到後端來處理。

第一點和第三點比較容易理解，這裡就不展開描述。我們重點來看看第二點：布隆過濾器。

布隆過濾器

布隆過濾器主要用於判斷一個元素是否在一個集合中。它是由一個固定大小的二進位向量（可理解成預設為0的bit數組）和一系列的映射函數組成的。

我們首先來看看布隆過濾器是如何標記一個資料a的：

• #第一步，會使用到多個映射函數（雜湊函數），每個函數都會計算這個資料a的雜湊值；
• 第二步，這些計算得出的雜湊值會分別對bit數組長度取模，這樣就得到每個雜湊值在數組上的位置；
• 第三步，把第二步得到的位置，分別在bit數組上設定為1。

透過這3個步驟，資料標記就完成了。然後要查詢資料在不在的時候是這樣做的：

• 先計算這個資料在bit數組中的多個位置；
• 然後分別查看bit數組的這些位置的bit值。只有每個位置的bit值都為1，表示資料才可能存在，否則資料一定不存在。

結合下圖來看，基本原理就是這樣。

推薦學習：Redis影片教學

以上がRedis キャッシュ雪崩、キャッシュのブレークダウン、キャッシュの侵入を 1 つの記事で理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。