Redis アプリケーションの問題と解決策

目次

1. キャッシュの侵入

        1.1 問題の説明

         1.2 解決策

 2. キャッシュの内訳

        2.1 問題の説明

         2.2 解決策

 3. キャッシュなだれ

        3.1 問題の説明

        3.2 解決策


        データベースへの負荷が増大すると、データベースにアクセスするサービスへの応答が遅くなり、サービスへの負荷が増大し、最終的にサービスのダウンタイムが発生する可能性があります。

1. キャッシュの侵入

        1.1 問題の説明

        キーに対応するデータがデータベースに存在しないため、キーに対する各リクエストはキャッシュから取得できないため、データベースにリクエストが行われます。このキーに対するリクエストが多数あると、データベースへの負荷が増大し、データベースのダウンタイムが発生します。

        この時点ではキャッシュはまだスムーズに実行されていますが、効果はありません。

        たとえば、存在しないユーザー ID を使用してユーザー情報を取得した場合、データはキャッシュにもデータベースにも存在しません。ハッカーがこの脆弱性を悪用すると、データベースが過負荷になる可能性があります。

         1.2 解決策

        存在してはいけないキャッシュとクエリできないデータ。データベースでデータが見つからず、キャッシュに書き込まれない場合、データはキャッシュで見つからないため、各リクエストをデータベースでクエリする必要があります。これにより、キャッシュが無意味になります。

  • null 値をキャッシュする: データベースからデータがクエリされない場合、戻り値は null です。存在するかどうかに関係なく、null 値 (null) はキャッシュされますが、null 値の有効期限は非常に短いため、 5分以上です。一時的な解決策としてのみ使用できます。
  • アクセシブル リスト (ホワイトリスト) を設定する: ビットマップ タイプを使用してアクセシブル リストを定義します。リスト ID はビットマップのオフセットとして使用されます。各アクセスはビットマップ内の ID と比較されます。ID がビットマップ内にない場合、ID は傍受され、アクセスは許可されません。
  • ブルームフィルタを使用する: ブルームフィルタの最下層でもハッシュを使用するため、スペース効率とクエリ時間効率が高いという利点がありますが、一定の誤認識率と削除の困難さが欠点です。
  • リアルタイム監視の実施:redisキャッシュのヒット率が急激に低下していることが判明した場合、アクセス対象やアクセスデータを確認し、運用保守担当者と連携してブラックリストを設定しアクセスを制限します。

 2. キャッシュの内訳

        2.1 問題の説明

        キーに対応するデータは存在しますが、redis 内で有効期限が切れています。この時点で多数の同時リクエストがある場合、これらのリクエストはキャッシュの有効期限が切れていることがわかり、リクエストはデータベースに送信されます。データが見つかった後、リクエストはデータベースに送信されます。 、データは Redis にキャッシュされます。現時点では、多数の同時リクエストによりデータベースが瞬時に超過してしまう可能性があります。

        同時に大量のリクエストがあり、リクエストは Redis 内の期限切れデータに対するもので、リクエストはデータベースに転送されます。リクエストの数が多いと、データベースに過剰な負荷がかかり、データベースのダウンタイムが発生します。

        現象: 1. データベースへの負荷が瞬間的に増加します。2. Redis にはキーの有効期限があまりありません。3. redis は正常に実行されており、圧力は上昇していません。

        理由: 1. Redis 内の特定のキーの有効期限が切れており、大量のアクセスがこのキーを使用しています。

         2.2 解決策

        キーは特定の時点で同時にアクセスされる可能性があり、非常にホットなデータです。キャッシュ内のキーの有効期限が切れると、データベースへの負荷が増大し、ダウンタイムやキャッシュの故障につながります。

  • 人気のあるデータを事前に設定する: Redis へのアクセスがピークになる前に、人気のあるデータを事前に Redis に保存し、これらの人気のあるデータ キーの有効期限を長くします。
  • リアルタイム調整: どの人気データを監視しているか、どのデータが頻繁にアクセスされているかをオンサイトで監視し、鍵の有効期限をリアルタイムに調整します。
  • ロックを使用:
    • キャッシュの有効期限が切れた場合(取り出した値が空と判断される場合)、データベースにはすぐにはアクセスされません。
    • まず、成功した操作の戻り値を含むキャッシュ ツールのいくつかの操作 (redis の setnx など) を使用して、ミューテックス キーを設定します。
    • 操作が正常に返されると、データベースを要求する操作が実行され、キャッシュがセットバックされ、最終的にミューテックス キーが削除されます。
    • 操作が戻らない場合は、データベースにアクセスしているスレッドが存在することが証明され、現在のスレッドは一定時間待機してからキャッシュ取得メソッド全体を再試行します。
    • ロックの欠点は効率の低下につながります。毎回 1 つのスレッドのみがデータベースにアクセスできます。

 3. キャッシュなだれ

        3.1 問題の説明

        キーに対応するデータは存在しますが、redis では期限切れになります。現時点で多数の同時リクエストがある場合、通常、これらのリクエストはリクエストをデータベースに送信し、キャッシュに問題があることが判明した場合はデータをキャッシュに戻します。このとき、大量の同時リクエストが瞬時にデータベースを圧倒し、データベースのダウンタイムが発生します。

        キャッシュ アバランシェとキャッシュ ブレークダウンの違いは、キャッシュ アバランシェは多数のキーの有効期限がターゲットであるのに対し、キャッシュ ブレークダウンは 1 つのキーの有効期限のみがターゲットであることです。

        現象: 1. 非常に短期間に、Redis 内の多数のキーの有効期限が切れます。

        3.2 解決策

        キャッシュの無効化による雪崩の問題は、基盤となるシステムに深刻な影響を与えます。

  • マルチレベルのキャッシュ アーキテクチャを構築します: nginx キャッシュ + redis キャッシュ + その他のキャッシュ (echache など)。Redis が処理できない場合は、他のキャッシュを検索します。
  • ロックまたはキューを使用する: ロックまたはキューを使用して、多数のスレッドが一度にデータベースに大量にアクセスしないようにします。これにより、障害時に基盤となるストレージ システムに多数の同時リクエストが発生することが防止されますが、これは同時実行性が高い状況には適していません
  • キャッシュを更新するために有効期限フラグを設定します。キャッシュされたデータの有効期限が切れたかどうかを記録します (事前量を設定します)。有効期限が切れた場合は、バックグラウンドで実際のキー キャッシュを更新するために別のスレッドへの通知がトリガーされます。
  • キャッシュの有効期限を分散する: たとえば、ランダム分岐 1 ~ 5 など、元の有効期限にランダムな値を追加することで、各キャッシュの有効期限の繰り返し率が減少し、キャッシュの有効期限が長くなるのを防ぐことができます。集団故障時です。

おすすめ

転載: blog.csdn.net/weixin_57023347/article/details/130086245
おすすめ