Redis キャッシュの 3 つの主要な例外に対処する方法

1. 背景

Redis は、完全にオープン ソースの BSD 準拠の高性能のキーと値のデータ構造です。ストレージ システムはデータの永続性をサポートし、データをディスク上のメモリに保存できます。単純なキー値型のデータだけでなく、リスト、セット、zset、ハッシュなどのデータ構造のストレージも提供します。この機能は非常に強力です。 Redis はデータ バックアップ、つまりマスター/スレーブ モードでのデータ バックアップもサポートしているため、可用性が向上します。高速な読み取りおよび書き込み速度は、日常の開発で最も頻繁に使用されるキャッシュ ソリューションとして広く使用されているため、最も重要です。しかし、実際のアプリケーションプロセスでは、キャッシュ雪崩、キャッシュ破壊、キャッシュペネトレーションなどの異常事態が発生し、これらの状況を無視すると致命的な結果を招く可能性があります。以下では主にこれらのキャッシュ例外と一般的な処理ソリューションを分析し、まとめます。 。

2. キャッシュ雪崩

(1)

とは 一定期間内にredisキャッシュ内で処理されるべき大量のリクエストデータベースの処理により、データベースへの負荷が急激に増加します。ひどい場合には、データベースがクラッシュし、雪崩のようにシステム全体が崩壊し、連鎖効果が引き起こされる可能性もあります。したがって、これはキャッシュ雪崩と呼ばれます。

(2) 理由

上記の状況が発生する一般的な理由は、主に次の 2 点です。同時にキャッシュされたデータの量が期限切れになるため、キャッシュから要求されるべきデータをデータベースから再取得する必要が生じます。

• redis 自体に障害が発生してリクエストを処理できない場合、当然のことながらデータベースに対して別のリクエストが行われます。

# (3) 対処方法

• #大量のキャッシュデータが同時に期限切れになった場合:

実際に有効期限を設定するときは、多数のキーが同時に期限切れになるようなシナリオを避けるようにしてください。そうなった場合は、ランダム化、微調整、および有効期限を設定してください。同時に期限切れを避けるための設定も行います。

キャッシュの構築操作が同時に実行されないように、ミューテックスを追加します。
デュアル キー戦略、主キーは元のキャッシュ、バックアップ キーはコピー キャッシュです。主キーに障害が発生した場合、バックアップ キーにアクセスできます。キャッシュの有効期限主キーは短期に設定され、バックアップキーは長期に設定されます。
バックグラウンド更新キャッシュ戦略。スケジュールされたタスクまたはメッセージ キューを使用して Redis キャッシュなどを更新または削除します。
• redis 自体に障害が発生した場合:

予防レベルでは、マスター/スレーブを通じて構築できます。ノード 高可用性クラスターとは、メイン Redis インスタンスがハングアップした後、他のスレーブ ライブラリがすぐにメイン ライブラリに切り替えてサービスを提供し続けることができることを意味します。

イベントが発生すると、リクエストが多すぎることによるデータベースのクラッシュを防ぐために、サービス サーキット ブレーカーまたはリクエスト電流制限戦略を採用できます。もちろん、サービスサーキットブレーカーは比較的ラフで、redis サービスが復元されるまでサービスを停止し、リクエスト電流制限は比較的緩やかで、一部のリクエストは確実に処理できます。ただし、特定のビジネス状況に基づいて適切なソリューションを選択する必要があります。
• 3. キャッシュの故障

(1)

とは キャッシュの故障は一般に、同時実行性の高いシステムで発生します。多数の同時ユーザーが、キャッシュにはないがデータベースに存在するデータを同時に要求します。つまり、同時にキャッシュは読み取りますが、データは読み取りません。同時にデータベースにアクセスしてデータを取得するため、インスタントなエラーが発生します。データベースの負荷が増大します。キャッシュ雪崩とは異なり、キャッシュ ブレークダウンは同じデータに対する同時クエリを指します。キャッシュ雪崩とは、異なるデータの有効期限が切れ、大量のデータが見つからないため、データベースが検索されることを意味します。 (2) 理由

この状況の一般的な理由は、特定のホット データ キャッシュの有効期限が切れていることです。ホット データであるため、同時リクエストの数が多く、まだリクエストが存在しません。大量のリクエストが同時に受信され、キャッシュが更新される前にすべてのリクエストがデータベースにヒットします。

(3) 対処方法

この状況に対する一般的な解決策は 2 つあります。

単純で粗雑です。ホットスポット データの有効期限を設定すると、有効期限が切れなくなり、当然上記のような状況は発生しません。後でクリーンアップしたい場合は、バックグラウンドで実行できます。

ミューテックス ロックを追加します。つまり、最初のクエリ リクエストを除き、ロックの有効期限が切れた後、ロック リクエストをデータベースから取得して再度キャッシュに更新できます。その他のロック リクエストも同様です。ロックが解放され、新しいキャッシュが更新されるまでブロックされ、その後のリクエストはキャッシュに対して行われるため、キャッシュの破壊は発生しません。

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

(1)

キャッシュペネトレーションとは、データが Redis にも Redis In にも存在しないことを意味します。これは、リクエストが届くたびに、対応するキーがキャッシュ内に見つからなかったため、毎回データベースを再度検索する必要があり、データベースにキーがないことが判明することになります。これは同等です。無駄なクエリが 2 つあります。このようにして、リクエストはキャッシュをバイパスしてデータベースを直接チェックすることができ、この時点で誰かが悪意を持ってシステムを攻撃したい場合、意図的に null 値やその他の存在しない値を使用して頻繁にリクエストを行うことができます。データベースに大きな負荷がかかります。

(2) 理由

この現象の理由は実は簡単で、ビジネスロジックにおいて、ユーザーが特定の情報に対して対応する操作や処理を行っていない場合、対応するストレージが情報 当然のことながら、データベースやキャッシュに該当するデータが存在しないため、上記の問題が発生しやすくなります。

(3) 対処方法

キャッシュの侵入には、通常、次の 3 つの解決策があります。

• 不正なリクエスト 制限事項主にパラメータ検証や認証検証などを指し、大量の不正リクエストを最初から遮断するためのもので、実際のビジネス展開においては必要な手段です。

• 空の値またはデフォルト値をキャッシュします。キャッシュから取得できないデータがデータベースに取得されない場合でも、空の結果をキャッシュし、より大きな値を設定します。有効期限が短い。この設定のデフォルト値はキャッシュに保存されるため、データベースへのアクセスを継続せずに 2 回目にキャッシュから取得したときに値が得られます。これにより、多数の悪意のあるリクエストが同じキーを繰り返し使用して、攻撃。

• ブルーム フィルターを使用して、データが存在するかどうかをすばやく判断します。ブルーム フィルターとは何ですか? 簡単に言うと、複数の独立したハッシュ関数を導入して、要素の重みの決定が所定の空間と誤判定率内で完了することを保証します。ハッシュ衝突のような状況が存在することがわかっているので、1 つのハッシュ関数だけを使用すると、衝突の可能性が明らかに増加します。この衝突を減らすために、さらにいくつかのハッシュ関数を導入し、ブルーム フィルタリングをコアとします。ハッシュ アルゴリズムの考え方は、複数の異なるハッシュ関数を使用してそのような競合を解決することです。利点は、スペース効率が高く、クエリ時間が他のアルゴリズムをはるかに上回る短いことですが、欠点は、一定の誤認識率が存在することです。要求されたキーがブルーム フィルターの検証を通過することを完全に保証することはできません。すべて、理論的には、確率がどれほど小さいとしても、依然として紛争は存在します。ただし、ブルーム フィルターの検証に合格しない限り、キーは存在してはなりません。これを使用する限り、存在しないキーに対するほとんどのリクエストを実際にフィルターで除外することができ、通常のシナリオではこれで十分です。

5. その他

上記の 3 つの一般的な Redis キャッシュ例外の問題に加えて、キャッシュの予熱とキャッシュのダウングレードという 2 つの用語は、そうではありません。これらは 2 つの最適化方法であるため、多くの例外問題が発生します。

(1) キャッシュの予熱

システムがオンラインになる前後に、キャッシュの予熱により、ユーザーの操作に依存することなく、関連するキャッシュ データがキャッシュ システムに直接読み込まれます。これにより、最初にデータベースにクエリを実行し、ユーザーが要求したときにデータをキャッシュするという問題を回避できます。ユーザーは、事前に予熱されたキャッシュ データに直接クエリを実行するため、システム起動の初期段階でデータベースにアクセスする同時実行性の高いトラフィックが発生し、データベースにトラフィックの負荷がかかることを回避できます。

データのさまざまな大きさに応じて、次の方法を使用できます:

• データの量は大きくありません: Project Start は自動的にロードされます。

• 大量のデータ: バックグラウンドで定期的にキャッシュを更新します。

• データの量が非常に多い: ホットスポット データのプリロード キャッシュ操作のみを実行します。

(2) キャッシュ ダウングレード

キャッシュ ダウングレードとは、キャッシュに障害が発生した場合、またはキャッシュ サービスに問題が発生した場合に、キャッシュ サービスの障害を防ぐために、キャッシュ サービスのダウングレードを意味します。データベースに雪崩の問題が発生するため、データベースにはアクセスしませんが、何らかの理由で、サービスに損傷を与えることは間違いありませんが、サービスが基本的に利用可能であることを確認したいと考えています。したがって、重要でないキャッシュされたデータに対しては、サービス低下戦略を採用できます。

一般的なアプローチは 2 つあります。

• メモリ部分のデータ キャッシュに直接アクセスします。

• システムによって設定されたデフォルト値を直接返します。

以上がRedis キャッシュの 3 つの主要な例外に対処する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。