Redis のホットキーストレージの問題を分析し、例外をキャッシュするための解決策について説明します。-Redis-php.cn

この記事では、Redis の 3 つの一般的なキャッシュ異常、キャッシュの侵入、キャッシュのブレークダウン、キャッシュなだれについて説明します。これらを通じて、Redis のホットキーストレージの問題について説明します。！

Redis のホットキーストレージの問題を分析し、例外をキャッシュするための解決策について説明します。

関連する推奨事項: 「Redis キャッシュの一貫性、キャッシュの侵入、キャッシュのブレークダウン、キャッシュアバランシェの問題の分析」

キャッシュの侵入、キャッシュの破壊、キャッシュなだれは、Redis のインタビューや実際の開発の際に考慮する必要があることが多い問題です。多くの人は、この問題の起源、原因、解決策についてまだ明確にしていません。実際、生成された原理を注意深く分析することで、これら 3 つの状況に対する適切な解決策を見つけることができます。 [関連する推奨事項: Redis ビデオチュートリアル ]

この記事は、定義、ケース、危険性、解決策を通じて、これら 3 つの問題をすばやく理解するのに役立ちます。

あなたも、これら 3 つの問題に対する多くの解決策をインターネット上で目にしたことがあるかと思いますが、これらの解決策のいくつかは 正しい解決策ですか?この記事では、そのようなソリューションの長所と短所を 1 つずつ分析します。

下の図はこの記事の内容概要を示しており、記事ではこれらの点についても分析してまとめています。

Redis のホットキーストレージの問題を分析し、例外をキャッシュするための解決策について説明します。

キャッシュの侵入、キャッシュの内訳、およびキャッシュの 3 つの比較

雪崩は、キャッシュ内にデータが存在しないために発生し、データのクエリにデータベースが使用されます。
キャッシュされたデータが存在しないため、すべてのリクエストはデータベースに送信され、データベースに過剰な負荷がかかったり、サービスのクラッシュを引き起こしてシステム全体が使用できなくなることもあります。

#キャッシュの侵入定義: キャッシュの侵入は、クライアントが要求したデータがキャッシュに存在しないためです。、データベースにクエリを実行しますが、クライアントがクエリしたいデータがデータベースにないため、すべてのリクエストでデータベースクエリ操作が実行されます。

本当の問題は、データ自体が存在しないことです

。例: クライアントが製品の詳細を要求すると、製品 ID が送信されますが、この時点では、製品 ID は (キャッシュにもデータベースにも) 存在しません。その結果、この ID を持つ製品のデータが要求されるたびに、データベースに送信されます。

ハザード: 要求されたパラメーターに対応するデータがまったく存在しないため、毎回データベースが要求され、データベースへの負荷が増大したりサービスがクラッシュしたり、さらには他のビジネスモジュールに影響を与えたりすることもあります。これは、ユーザー

が悪意のあるリクエスト

を行った場合によく発生します。

解決策:

1. 要求されたパラメーターに基づいて null 値をキャッシュします。この値に有効期限を設定すると、時間を短く設定できます。

2. ブルームフィルターを使用します。まずブルームフィルターでフィルターします。フィルターにブルームフィルターが存在する場合は、データベースにクエリを実行してから、キャッシュに追加します。存在しない場合は、クライアントデータが存在しないことを直接返します。

3. キャッシュの侵入はユーザーによって開始された悪意のあるリクエストである可能性があるため、ユーザー IP を記録し、悪意のある IP リクエストをブロックすることができます。

スキーム分析:

ブルームフィルターの欠点の 1 つは、存在すると言われれば必ずしも存在するとは限らず、存在しないと言われれば存在しないことを意味することです。

計画の概要:

まず、リクエストレベルで 3 番目のソリューションを追加し、一部の悪意のあるリクエストを制御するための電流制限メカニズムと IP ブラックリストメカニズムを作成し、誤った判断があった場合には IP ブロック解除などの操作を実装します。。キャッシュ層は最初のソリューションを使用して実装されます。適切なキャッシュ時間を設定します。

誤った判断が許容されるビジネスシナリオの場合は、2 番目のソリューションを直接使用できます。完全に Redis に基づいているため、システムの複雑さが軽減されます。

#キャッシュブレークダウン
定義: 特定のホットキーが存在しないためにキャッシュブレークダウンが発生し、データベースがアクセスしてください。データベースに対する負荷が増大します。この圧力は一時的な場合もあれば、長期間続く場合もあります。
本当の問題は、キーが存在してもキャッシュに存在しないため、データベース操作が発生することです。
例: 人気のある商品があり、ユーザーが商品の詳細を表示するときに、商品 ID を使用して商品の詳細を取得します。現時点では、キャッシュ内のデータの有効期限が切れているため、すべての受信リクエストはデータベースに送信されてクエリを実行する必要があります。
ハザード: キャッシュの侵入と比較すると、データはデータベースに存在しますが、キャッシュの有効期限が切れているため、データベースに一度アクセスしてからキャッシュに追加する必要があり、次のリクエストは正常に続行できます。。いわゆる害はデータベースレベルにも向けられています。

解決策:
1. ミューテックスロックを追加します。最初のリクエストでは、キャッシュにデータが存在しないことが判明し、この時点でクエリデータベースがキャッシュに追加されました。このようにして、後続のリクエストではデータベースクエリを実行する必要がありません。
2. ビジネスロジックの有効期限を長くします。キャッシュを設定するときに、キャッシュの有効期限を追加できます。読み取るたびに判断し、有効期限が現在時刻より短い場合は、バックグラウンドスレッドをトリガーし、データベースにアクセスしてデータを取得し、キャッシュされたデータとキャッシュされた有効期限を更新します。実際、原則は、コードレベルでキャッシュのキャッシュ期間を延長することです。
3. データのウォームアップ。バックグラウンドでキャッシュへのデータの追加を実装します。たとえば、フラッシュセールシーンが開始される前に、商品の在庫がキャッシュに追加され、ユーザーのリクエストが来たときに直接キャッシュに移動します。
4. 有効期限はありません。キャッシュの有効期限を設定する場合は、期限切れにならないようにしてください。これらのキャッシュの有効期限とデータ更新を維持するために、別のスレッドがバックグラウンドで開かれます。

プログラム分析:

ミューテックスロックにより、データベースに送信されるリクエストが 1 つだけになることが保証されるため、これは利点です。しかし、分散システムでは、分散ロックを実装するために分散ロックが使用されるため、分散ロックの実装自体に一定の困難があり、システムの複雑さが増大します。

2 番目のソリューションは、Redis の有効期限が切れず、ビジネスが期限切れになるソリューションを使用して実装されます。これにより、リクエストごとにデータを確実に取得でき、バックグラウンドスレッドを使用してデータを更新することもできます。欠点は、バックグラウンドスレッドがデータの更新を完了していないことです。現時点では、要求されたデータは古いデータであるため、リアルタイム性の要件が高いビジネスシナリオでは不利になる可能性があります。

3 番目の解決策は、キャッシュの予熱を使用し、ロードされるたびにキャッシュすることであり、2 番目の解決策と似ています。ただし、ホットデータ更新の問題もあるため、このソリューションは高いリアルタイム性を必要としないデータに適しています。

4 番目のソリューションは 2 番目と 3 番目のソリューションに似ており、これに基づいて、バックグラウンドの非同期スレッドを使用してキャッシュされたデータをアクティブに更新するという特定の最適化が行われています。難しいのは、更新の頻度を制御することです。

スキームの概要:

リアルタイム要件が高いデータの場合は、最初のスキームを使用することをお勧めします。技術的には難しいですが、リアルタイムにデータを処理できます。一部のリクエストが長時間待機する場合、例外が返され、クライアントはリクエストを再送信できます。

高いリアルタイムパフォーマンスを必要としないデータの場合は、4 番目のソリューションを使用できます。

#キャッシュ雪崩定義: 前述のキャッシュの故障は、キャッシュ内の特定のホットスポットが原因です。キーが失敗すると、大量のリクエストがデータベースに送信されます。ただし、キャッシュ雪崩は実際には同じですが、こちらの方が深刻で、1 つまたは 2 つのキーではなく、キャッシュされたキーのほとんどが無効です。

例: 電子商取引システムでは、特定のカテゴリの商品データがキャッシュ内で無効です。ただし、現在のシステムからのリクエストの多くは、このカテゴリの製品データに対するものです。これにより、すべてのリクエストがデータベースクエリを通過するようになります。

危険性: 瞬時に大量のリクエストが殺到するため、各リクエストをデータベース内でクエリする必要があります。データベースへのトラフィックの瞬間的な流入は、データベースへの負担を大幅に増大させ、直接的なデータベース麻痺を容易に引き起こす可能性があります。

解決策:
1. キャッシュ時間はランダムです。特定の時刻に多数のキャッシュが期限切れになるため、キャッシュの期限切れ時間が比較的集中していることを意味します。有効期限を焦点を当てずにランダムに直接設定します。この方法では、キャッシュの有効期限があまり集中せず、データベースに対するクエリ操作のリクエストが同時に大量に発生することもありません。

2. マルチレベルキャッシュ。単に Redis に依存してキャッシュするのではなく、memcached をキャッシュに使用することもできます (これは単なる例であり、他のキャッシュサービスも使用できます)。データをキャッシュする場合は、Redis 用のキャッシュと memcached 用のキャッシュを作成します。 Redis が失敗した場合は、memcached を使用できます。

3. ミューテックスロック。キャッシュの内訳でミューテックスロックの使用について説明しましたが、アバランシェの場合にもミューテックスロックを使用できます。

4. 有効期限フラグを設定します。実際、キャッシュの内訳で説明した永久的な無期限を使用することもできます。リクエスト時に有効期限が決定され、有効期限が近づくと有効期限フラグが設定され、独立したスレッドがトリガーされてキャッシュが更新されます。

スキーム分析:

最初のスキームでは乱数のキャッシュ時間を使用し、キーの有効期限を確実に分散させます。難しいのはキャッシュ時間をどのように設定するかですが、キャッシュ時間が短く、データ量が非常に多い一部のデータの場合、このソリューションでは適切な時間制御が必要です。

2 番目のソリューションでは、マルチレベルキャッシュを使用して、すべてのリクエストがキャッシュされるようにします。ただし、これにより、システムのアーキテクチャの難しさが増し、マルチレベルの更新のキャッシュなど、その他のさまざまな問題が発生します。

3 番目のオプションはミューテックスロックを使用します。ミューテックスロックについてはキャッシュブレークダウンで説明しました。雪崩シナリオで使用できますが、これにより大量の配布が生成されます。スタイルロック。

4 番目のソリューションでは、論理キャッシュ時間を使用します。これにより、システムのキャッシュ圧力が十分に保証されます。

計画の概要:

実際のプロジェクトでは、1 番目、2 番目、4 番目のオプションを使用して試してみることをお勧めします。どちらが良いでしょう。

#概要

キャッシュの侵入は、データベース自体にデータがないことが原因です。

キャッシュの故障とキャッシュなだれは、データはデータベースに存在するが、キャッシュ内のデータが無効であるため、データベースが再度クエリされてからキャッシュに追加されることを意味します。

キャッシュの故障は一部のホットキーを対象としていますが、キャッシュなだれは大規模なキャッシュ障害です。キャッシュキーの分割が異なることを除いて、2 つの原則は実際には同じです。

プログラミング関連の知識について詳しくは、
プログラミング入門をご覧ください。！

以上がRedis のホットキーストレージの問題を分析し、例外をキャッシュするための解決策について説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。