1. キャッシュの侵入
1. キャッシュペネトレーションとは何ですか?
キャッシュの侵入とは、ユーザーが要求したデータがキャッシュにもデータベースにも存在しないことを意味し、ユーザーはデータを要求するたびにデータベースにクエリを実行することになります。悪意のある攻撃者がシステムに存在しないデータを要求し続けると、短期間に大量の要求がデータベースに降りかかり、データベースに過剰な圧力がかかったり、データベースが耐えられなくなったりすることがあります。それとクラッシュします。
キャッシュペネトレーションの鍵は、指定されたキー値が Redis で見つからないことです。キャッシュペネトレーションとの基本的な違いは、受信キーが Redis に存在しないことです。ハッカーが存在しないキーを大量に渡すと、大量のリクエストがデータベースに直接ヒットすることになり、非常に危険な状況になります。そのため、日々の開発ではパラメータの検証をしっかり行う必要があり、不正なパラメータや存在しないキーについては、直接エラーメッセージを返す必要があります。
以下に示すように:
2. 解決策
2.1 無効なキーが Redis に保存される
Redis がデータを見つけられず、データベース内でもデータが見つからない場合は、無効なキーを Redis に保存し、その値を「null」に設定し、非常に短い有効期限を設定できます。このようにして、このキーを照会する後続のリクエストが発生したときに、データベースを照会せずに直接 null を返すことができます。ただし、この処理方法には問題があります。つまり、存在しない受信キーが毎回ランダムである場合、それを Redis に保存する意味がありません。
2.2 ブルームフィルターの導入
ブルーム フィルターを導入して、キャッシュを使用する前にキーが存在するかどうかを判断できます。ブルームフィルターには一定の誤判定率がありますが、ブルームフィルターが特定のキーが存在しないと判定した場合はそのキーは存在しないと判定でき、特定のキーが存在すると判定した場合は高い確率で判定されます。それは存在します（一定の誤った判断率があります）。したがって、データベース内のすべてのキーをブルーム フィルターに保存し、Redis にクエリを実行する前に、ブルーム フィルターを通じてキーが存在するかどうかをクエリできます。ブルーム フィルターがキーが存在しないと判断した場合は、データベースにアクセスせずにキーを直接返すことができるため、基盤となるストレージ システムに対するクエリの負荷が軽減されます。この方法により、システムのパフォーマンスとクエリ効率を効果的に向上させることができます。
2.3 選択方法:
- 一部の悪意のある攻撃では、攻撃によってもたらされる多数のキーがランダムであるため、最初の解決策を使用すると、キーなしで大量のデータがキャッシュされます。このソリューションは適切ではないため、まずブルーム フィルター ソリューションを使用してこれらのキーをフィルターで除外します。
- したがって、キーの数が異常に多く、リクエストの繰り返し率が低いデータの場合は、2 番目の解決策を使用してデータを直接除外します。キーが限られており、繰り返し率が比較的高い空のデータの場合は、最初に最初の方法をキャッシュに使用できます。
2. キャッシュの内訳
1. キャッシュの内訳とは何ですか?
キャッシュのブレークダウンとキャッシュなだれは、2 つの似た現象です。キャッシュなだれとは、ある瞬間に大規模なキャッシュ障害が発生し、その結果、多数のリクエストがデータベースに直接アクセスし、データベースへの負荷が急激に増加することを指します。キャッシュ故障とは、特定のホットスポットのキャッシュ障害により、多数の同時リクエストがキャッシュに集中することを指しますが、キャッシュ障害により、これらのリクエストはキャッシュからデータを取得できず、データベースに直接アクセスすることしかできなくなります。増加し、データベースに深刻な負荷がかかります。
2. 解決策
ホットスポットキーは有効期限を設定しません
3. キャッシュなだれ
1. キャッシュアバランシェとは何ですか?
- ある瞬間にキャッシュ内の多数のキーが同時に無効になると、大量のリクエストがデータベースに直接アクセスすることになり、データベースに大きな負荷がかかります。同時実行性が高い状況では、データベースのダウンタイムのリスクが発生する可能性があります。運用保守担当者がすぐにデータベースを再起動すると、再び新しいリクエスト トラフィックが呼び込まれ、データベースに過剰な圧力がかかり続ける可能性があります。この状況はキャッシュ雪崩と呼ばれます。
- キャッシュ雪崩を引き起こす鍵となるのは、多数のキーが同時に期限切れになることです。
- この状況は 2 つの状況で発生する可能性があります: 1 つは Redis キャッシュがダウンし、すべてのキャッシュが無効になります。2 つ目は、キャッシュ内のキーが同じ有効期限に設定されており、多数のキーが同時に期限切れになります。 。
2. 解決策
2.1 一律の有効期限
統一した有効期限戦略を採用することができます。つまり、異なる有効期限を設定してキャッシュの無効化時間をできるだけ均一にし、同じ有効期限によって大規模なキャッシュが同時に期限切れになり、多数のデータベースが失効することを避けることができます。アクセスします。一般的なアプローチは、各キーの有効期限にランダムな値を追加して、広い領域で同時にキャッシュが期限切れにならないようにすることです。
2.2 ホットスポット データ キャッシュは期限切れになりません
ホットスポット データのキャッシュ障害によって引き起こされるキャッシュ雪崩を防ぐための一般的なアプローチは、ホットスポット データのキャッシュが期限切れにならないようにすることです。これは、頻繁にアクセスされるデータについては、キャッシュの有効期限を永続的に設定して、常にキャッシュ内に残るようにできることを意味します。このようにして、ホットスポット データは常に利用できるようになり、有効期限切れによって多数のリクエストがデータベースに直接アクセスすることがなくなり、データベースへの負担が軽減されます。もちろん、キャッシュされたデータの有効期限切れによるデータの不整合を避けるために、データの更新時に対応するキャッシュが時間内に更新されるようにする必要があります。このようにして、ホットスポット データのキャッシュはシステムに高速な応答を提供し続け、キャッシュの無効化によって引き起こされるキャッシュなだれの問題を効果的に回避できます。
2.3 電流制限とダウングレード戦略を採用する
リクエストが多すぎるとデータベースに過度の負荷がかかり、システムがクラッシュすることを防ぐために、電流制限およびダウングレード戦略を採用できます。システムのトラフィックが特定のしきい値に達すると、「システムの輻輳」などのプロンプト情報を直接返して、それ以上のリクエストを制限できます。このようにして、少なくとも一部のユーザーがシステムを正常に使用できることが保証され、他のユーザーについては、複数回の更新が必要な場合でも最終的に結果を取得できるようになります。
4. キャッシュのウォームアップ
1. キャッシュウォーミングとは何ですか?
- キャッシュの予熱とは、システムがオンラインになった後、関連するキャッシュ データを事前にキャッシュ システムにロードすることを意味します。ユーザーが要求したときに最初にデータベースにクエリを実行し、次にデータをキャッシュするという問題を回避するために、ユーザーは事前に予熱されたキャッシュ データに直接クエリを実行します。
- 予熱がない場合、Redis の初期状態データは空になり、システム起動の初期段階では、同時実行性の高いトラフィックがデータベースにアクセスし、データベースにトラフィックが圧迫されます。
2. 解決策
2.1 プロジェクト開始時にキャッシュをロードする
2.2 スケジュールされたタスク スクリプトを使用してキャッシュを更新する
2.3 ホットスポット データを事前にキャッシュにロードする
2.4 概要
- データ量が少ない場合は、プロジェクトの開始時にキャッシュロード操作を実行できます。
- データの量が多い場合は、スケジュールされたタスク スクリプトを使用してキャッシュを更新できます。
- データ量が多すぎる状況では、ホットスポット データが事前にキャッシュにロードされるようにすることを優先できます。
起動プロセス中にキャッシュをロードすると、データベースへの頻繁なアクセスが減り、システムの同時処理能力が向上します。
スケジュールされたタスク スクリプトを使用すると、キャッシュを定期的に更新して、データをタイムリーに更新できます。
データ量が多すぎる状況では、事前にホットスポット データをキャッシュにロードすると、頻繁なデータベース クエリが回避され、データベースへの負荷が軽減されます。
合理的なキャッシュ戦略とデータ読み込み方法を通じて、システムのパフォーマンスと安定性を最適化できます。