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

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

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

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

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

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

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

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

• 雪崩は、キャッシュ内にデータが存在しないために発生し、データのクエリにデータベースが使用されます。

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

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

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

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

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

が悪意のあるリクエスト

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

解決策:

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

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

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

スキーム分析:

最初のスキームは、存在しないキーの空の値をキャッシュします。このようなリクエストが多すぎると、それらはすべて null 値のキャッシュを 1 つずつ設定するのでしょうか? このとき、Redis には無効なキャッシュ null 値が大量に存在します。このキーを商品や記事のIDとした場合、null値を設定した後、バックグラウンドでデータが追加された場合には、そのIDに対応するキャッシュ値を更新し、適切な有効期限を設定する必要があります。
2 番目のソリューションは、業界で最も一般的に使用されているソリューションでもあります。ブルーム フィルターの利点は、Redis 実装、メモリ操作に基づいており、基礎となる実装も非常にメモリを節約できることです。バックグラウンドでデータが正常に追加されると、データの ID がブルーム フィルターに追加され、リクエストを行う際、フロントエンドはまずブルーム フィルターを通過してデータが存在するかどうかを確認します。しかし、ブルームフィルターにはハッシュ競合の問題という欠点もあります。ここでのハッシュの競合は何を意味するのでしょうか?つまり、複数のIDをハッシュ化した場合、得られるハッシュビットは同じ値となり、存在確認の際に誤判定を招くことになる。それ自体には何かがありますが、結果には何もありません。
• ブルーム フィルターの欠点の 1 つは、存在すると言われれば必ずしも存在するとは限らず、存在しないと言われれば存在しないことを意味することです。

3 番目のオプションは、一定期間内に同じユーザーに対して多数のリクエストを開始し、キャッシュ侵入メカニズムをトリガーすることです。クライアントのアクセス。ただし、攻撃者が DDOS 攻撃を開始した場合、その攻撃を完全に回避することはできないため、このソリューションは良い解決策ではありません。

計画の概要:

• まず、リクエスト レベルで 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 サイトの他の関連記事を参照してください。