Redis の 3 つのキャッシュの問題について話しましょう-Redis-php.cn

この記事では、Redis に関する関連知識を提供します。主に、キャッシュの侵入、キャッシュの破壊、キャッシュなだれという 3 種類のキャッシュの問題について紹介します。皆様のお役に立てれば幸いです。

Redis の 3 つのキャッシュの問題について話しましょう

# 推奨学習:

Redis 学習チュートリアル

#1. Redis キャッシュのアプリケーション

実際のビジネスシナリオでは、Redis は通常、リレーショナルデータベースなどのバックエンドデータベースへの負荷を軽減するために、他のデータベースと組み合わせて使用されます。データベース MySQL を使用します。

Redis は、ホットデータなどの頻繁にクエリされるデータを MySQL にキャッシュします。そのため、ユーザーがアクセスするときに、MySQL でクエリを実行する必要はなく、Redis でキャッシュされたデータを直接取得できるため、バックエンドデータベースに対する読み取りの負荷が軽減されます。

ユーザーがクエリしたデータが Redis で利用できない場合、ユーザーのクエリリクエストは MySQL データベースに転送されます。

MySQL がデータをクライアントに返すとき、データもキャッシュされます。 Redis のにあるデータを保存することで、ユーザーが再度読み取るときに Redis から直接データを取得できるようになります。フローチャートは次のとおりです。

もちろん、
Redis をキャッシュデータベースとして常に使用できるわけではありません。順風満帆ですが、よくある 3 つのキャッシュの問題 :

##キャッシュの侵入
# に遭遇します。 #キャッシュの内訳

キャッシュなだれ

#、キャッシュの侵入

2.1 はじめに

キャッシュの侵入

とは、
ユーザーが特定のデータをクエリすると、そのデータが Redis に存在しないことを意味します。このデータは、キャッシュがヒットしません。この時点で、クエリリクエストは永続化レイヤーデータベース MySQL に転送されます。データが MySQL に存在しないことがわかります。MySQL は空のオブジェクトのみを返すことができます。これは、クエリが失敗したことを意味します。このタイプのリクエストが多すぎる場合、またはユーザーがこの種のリクエストを使用して悪意のある攻撃を実行すると、MySQL データベースに多大な負荷がかかり、データベースが崩壊することもあります。この現象はキャッシュ侵入と呼ばれます。
#2.2 解決策

空のオブジェクトをキャッシュする

MySQL が空のオブジェクトを返すと、Redis はオブジェクトをキャッシュし、有効期限を設定します。

ユーザーが同じリクエストを再度開始すると、

空のオブジェクトがキャッシュから取得されます。ユーザーのリクエストはキャッシュ層でブロックされるため、バックエンドデータベースが保護されますが、このアプローチにはいくつかの問題もあり、リクエストは MSQL に入ることができませんが、Redis キャッシュスペースを占有します。 #ブルームフィルター

ユーザーがアクセスできるフィルターを最初に配置します。ホットスポットデータのすべてのキーは、ブルームフィルター (キャッシュの予熱とも呼ばれます) に保存されます。ユーザーがリクエストすると、まずブルームフィルター、

ブルームフィルターを通過します。要求されたキーが存在するかどうかを判断します。。キーが存在しない場合、リクエストは直接拒否されます。そうでない場合、クエリは実行され続けます。最初にキャッシュにアクセスしてクエリを実行します。キャッシュが存在しない場合は、、次にデータベースに移動してクエリを実行します。最初の方法と比較して、ブルームフィルター方法を使用する方が効率的かつ実用的です。 プロセス図は次のとおりです。

##キャッシュの予熱

: キャッシュの予熱を指します。システムが開始されます。関連するデータが Redis キャッシュシステムにロードされます。これにより、ユーザーが要求したときにデータをロードすることがなくなります。

2.3 ソリューションの比較

両方のソリューションはキャッシュ侵入の問題を解決できますが、使用シナリオは異なります:

空のオブジェクトをキャッシュする: 空のデータのキーの数が限られており、キー要求が繰り返される可能性が高いシナリオに適しています。

ブルームフィルター: 空のデータのキーが異なり、キー要求が繰り返される可能性が低いシナリオに適しています。

#3. キャッシュの内訳

3.1 はじめに

キャッシュの内訳とはユーザーによってクエリされたデータはキャッシュには存在しませんが、バックエンドデータベースには存在します。この現象の理由は、通常、はキャッシュ内のキーの有効期限切れによって引き起こされるためです。たとえば、ホットデータキーは常に大量の同時アクセスを受けますが、ある瞬間にキーに突然障害が発生すると、大量の同時リクエストがバックエンドデータベースに入り、その負荷が瞬時に高まります。この現象をキャッシュブレイクといいます。

3.2 解決策

有効期限を変更する

ホットスポットデータを無期限に設定する。

分散ロック

分散ロック方式を採用してキャッシュを再設計します。

Lock: キーでデータをクエリするときは、まずキャッシュをクエリします。ロックは分散ロックを通じて実行され、ロックを取得する最初のプロセスはバックエンドデータベースにアクセスしてクエリを実行し、クエリ結果を Redis にバッファリングします。

ロック解除: 他のプロセスは、ロックがプロセスによって占有されていることを検出すると、待機状態に入ります。ロックを解除した後、他のプロセスはキャッシュされたキーに順番にアクセスします。 . .

3.3 ソリューションの比較

無期限: このソリューションには実際の設定がありません。有効期限を設定すると、実際にはホットキーによって引き起こされる一連の危険が排除されますが、データの不整合が発生し、コードの複雑さが増加します。

Mutex lock: この解決策は比較的シンプルですが、キャッシュの構築プロセスに問題がある場合や、時間がかかる場合には、特定の隠れた危険性があります。ロックやスレッドプールのブロックのリスクはありますが、この方法によりバックエンドストレージの負荷が軽減され、より良い一貫性が実現されます。

4. キャッシュなだれ

4.1 はじめに

##キャッシュなだれとは、キャッシュ内の大きなバッチを指します。同時にキーの有効期限が切れ、このときのデータアクセス量が非常に多くなるため、バックエンドデータベースへの負荷が急激に高まり、クラッシュすることもあります。この現象はキャッシュ雪崩と呼ばれます。キャッシュブレークダウンとは異なります。キャッシュブレークダウンは同時実行量が特に多いときに特定のホットキーが突然期限切れになるときに発生しますが、キャッシュアバランシェは多数のキーが同時に期限切れになるときに発生するため、同じ順序ではありません。まったく規模が大きい。
#4.2 解決策

有効期限の処理