Redis キャッシュ問題の分析例

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

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

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

ユーザーがクエリしたデータが Redis で利用できない場合、ユーザーのクエリ リクエストは MySQL データベースに転送されます。MySQL がデータをクライアントに返すと、データは Redis にキャッシュされます。 これにより、ユーザーが再度読み取るときに、Redis からデータを直接取得できるようになります。フローチャートは次のとおりです。

#Redis をキャッシュ データベースとして使用すると、必然的に 3 つの一般的なキャッシュの問題に直面することになります

#キャッシュ ペネトレーション

• キャッシュ ペネトレーション

• キャッシュ雪崩

• 2. キャッシュ侵入

2.1 はじめに

キャッシュ侵入とは、次のことを意味します。ユーザーがあるデータをクエリすると、そのデータはRedis上に存在しない、つまりキャッシュがヒットしませんが、このときクエリリクエストは永続層データベースMySQLに転送され、データが存在することが分かります。 MySQL にも存在しません。MySQL はクエリが失敗したことを示す空のオブジェクトのみを返すことができます。このようなリクエストが多数存在したり、ユーザーがそのようなリクエストを利用して悪意のある攻撃を行ったりすると、MySQL データベースに大きな負荷がかかり、場合によっては崩壊する可能性があり、この現象はキャッシュペネトレーションと呼ばれます。

#2.2 解決策

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

MySQL の場合空のオブジェクトが返された場合、Redis はオブジェクトをキャッシュし、有効期限を設定します。 ユーザーが同じリクエストを再度開始すると、空のオブジェクト

がキャッシュから取得されます。ユーザーのリクエストはキャッシュ層でブロックされるため、バックエンド データベースが保護されます。ただし、このアプローチではリクエストは MSQL に入ることができませんが、この戦略は

Redis キャッシュ スペースを占有します。

ブルーム フィルター

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

. 存在しない場合、その場合、リクエストは直接拒否されます。それ以外の場合、クエリは引き続き実行されます。最初にキャッシュに移動してクエリを実行し、キャッシュが存在しない場合は、次にデータベースに移動してクエリを実行します。最初の方法と比較して、

ブルーム フィルター方法を使用する方が効率的かつ実用的です。 プロセス図は次のとおりです:

キャッシュの予熱は、システムが実行される前に、関連するデータを Redis キャッシュ システムに事前にロードするプロセスです。始まります。これにより、ユーザーが要求したときにデータをロードすることがなくなります。

#2.3 ソリューションの比較

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

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

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

3. キャッシュの内訳
3.1 はじめに

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

3.2 解決策

有効期限を変更する

ホットスポット データが期限切れにならないように設定します。

分散ロック

分散ロック方式を採用してキャッシュの使用を再設計します。プロセスは次のとおりです:

• ロック: キーを介してデータをクエリするときは、最初にキャッシュをクエリします。そうでない場合は、分散ロックを介してロックします。ロックを取得する最初のプロセス Enter the back -データベースクエリを終了し、クエリ結果を Redis にバッファリングします。

• ロック解除: 他のプロセスは、ロックが特定のプロセスによって占有されていることを認識すると、待機状態に入ります。ロック解除後、他のプロセスはキャッシュされたキーにアクセスします。振り向く。 。

3.3 ソリューションの比較

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

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

4. キャッシュなだれ

4.1 はじめに

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

#4.2 解決策

有効期限の処理

同時に期限切れになる多数のキーによって引き起こされるキャッシュの故障と雪崩の問題を軽減するために、キャッシュ雪崩と同様に、ホットスポット データを期限切れにしない戦略を採用できます。さらに、キーが同時に期限切れになるのを防ぐために、キーにランダムな有効期限を設定できます。

redis の高可用性

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

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