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 解決策

有効期限の処理

キャッシュ雪崩とキャッシュ ブレークダウンは似ているため、ホットスポット データは期限切れにならない

メソッドを使用して、多数のキーの同時有効期限を減らすこともできます。さらに、

キーの有効期限が集中的に失われるのを避けるために、キーにランダムな有効期限を設定します。

redis の高可用性

雪崩により 1 つの Redis がハングする可能性があるため、さらにいくつかの Redis を追加できます, クラスターを構築します。1 つが失敗しても、他のクラスターは引き続き動作します。

推奨学習: Redis 学習チュートリアル

以上がRedis の 3 つのキャッシュの問題について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。