Redis キャッシュ例外が発生した場合はどうすればよいですか?の解き方？

Redis キャッシュ例外が発生した場合はどうすればよいですか?次の記事では、Redis キャッシュの例外と解決策について説明します。

キャッシュなだれ

キャッシュなだれとは、同時に広範囲のキャッシュ障害が発生することを指します。そのため、後続のリクエストはがデータベースに落ち、短期間に大量のリクエストが発生したためにデータベースが崩壊します。 [関連する推奨事項: Redis ビデオ チュートリアル ]

ソリューション

1. キャッシュされたデータの有効期限をランダムに設定します。多数のデータが同時に期限切れになるのを防ぎます。

2. 一般に、同時実行の量が特に大きくない場合、最も一般的に使用される解決策はロック キューイングです。

3. キャッシュされた各データに対応するキャッシュ タグを追加し、キャッシュが無効かどうかを記録します。キャッシュ タグが無効な場合は、データ キャッシュを更新します。

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

キャッシュ ペネトレーションとは、キャッシュにもデータベースにも存在しないデータを指し、すべてのリクエストがデータベースに落ち、結果として短期間の時間がかかります。データベース内の時間 大量のリクエストによりクラッシュしました。

解決策

1. ユーザー認証検証などの検証をインターフェイス層に追加します。ID は基本的な検証を行い、ID

2. キャッシュから取得できないデータはデータベースには取得されません。このとき、キーと値のペアは key-null として書き込むこともでき、キャッシュの有効期間は30秒など短く設定してください（長すぎると通常は使用できなくなります）。これにより、攻撃ユーザーが同じ ID を繰り返し使用してブルート フォース攻撃を行うことを防ぐことができます。

3. ブルーム フィルターを使用して、すべての可能なデータを十分な大きさのビットマップにハッシュします。存在してはいけないデータはインターセプトされます。このビットマップを使用することで、基盤となるストレージ システムに対するクエリのプレッシャーを回避できます。

追加

スペースの究極の使い方は、ビットマップとブルーム フィルターです。

ビットマップ: 典型的なものはハッシュ テーブルです。

欠点は、ビットマップは各要素に対して 1 ビットの情報しか記録できないことです。追加の関数を完成させたい場合は、 、より多くの空間と時間を犠牲にすることによってのみ達成できるのではないかと思います。

ブルーム フィルター (推奨)

k(k>1)k(k>1) の独立したハッシュ関数を導入して、指定された空間と誤判定率の下で、要素の重みを決定するプロセスが完了します。

利点は、スペース効率とクエリ時間が一般的なアルゴリズムよりもはるかに高いことですが、欠点は、一定の誤認識率と削除が難しいことです。

ブルーム フィルター アルゴリズムの中心となるアイデアは、複数の異なるハッシュ関数を使用して「競合」を解決することです。

ハッシュには競合 (衝突) の問題があり、同じハッシュを使用して取得された 2 つの URL の値が同じになる可能性があります。競合を減らすために、さらにいくつかのハッシュを導入することができます。ハッシュ値の 1 つによって要素がセットに含まれていないことが判明した場合、その要素は間違いなくセットに含まれていません。すべてのハッシュ関数が要素がセット内にあることを示す場合にのみ、要素がセット内に存在することを確認できます。これがブルームフィルターの基本的な考え方です。

ブルーム フィルターは通常、大規模なデータ コレクションに要素が存在するかどうかを判断するために使用されます。

キャッシュ ブレークダウン

キャッシュ ブレークダウンとは、キャッシュ内にはないがデータベース内に存在するデータを指します (通常、キャッシュ時間の期限が切れています)。同時ユーザーの特殊な性質による 多くの場合、データが同時にキャッシュに読み取られるのではなく、同時にデータベースからデータがフェッチされるため、データベースへの負荷が瞬時に増大し、過剰な負荷が発生します。キャッシュ雪崩とは異なり、キャッシュ ブレークダウンは同じデータに対する同時クエリを指します。キャッシュ雪崩とは、異なるデータの有効期限が切れ、大量のデータが見つからないため、データベースが検索されることを意味します。

解決策

1. ホットスポット データが期限切れにならないように設定します

2. ミューテックス ロック、ミューテックス ロックを追加します

キャッシュの予熱

キャッシュの予熱とは、システムがオンラインになった後、関連するキャッシュ データをキャッシュ システムに直接ロードすることを意味します。このようにして、最初にデータベースにクエリを実行し、ユーザーが要求したときにデータをキャッシュするという問題を回避できます。ユーザーは、予熱されたキャッシュ データを直接クエリします。

解決策

1. キャッシュ更新ページを直接作成し、オンラインになるときに手動で実行します;

2. データ量は問題ありません。規模が大きい場合は、プロジェクトの開始時に自動的にロードすることができます。

3. キャッシュを定期的に更新します。

キャッシュのダウングレード

アクセス数が増加した場合急にサービスの問題が発生したり (応答時間が遅い、または応答しない場合)、または非コア サービスがコア プロセスのパフォーマンスに影響を与える場合、サービスが侵害された場合でも、サービスが引き続き利用可能であることを確認する必要があります。システムは、いくつかの重要なデータに基づいて自動的にダウングレードすることも、手動でダウングレードできるようにスイッチを構成することもできます。

キャッシュ ダウングレードの最終的な目標は、たとえ損失があったとしても、コア サービスが確実に利用できるようにすることです。また、一部のサービスはダウングレードできません (ショッピング カートへの追加、チェックアウトなど)。

ダウングレードする前に、システムが兵士を失い、指揮官を維持できるかどうかを確認する必要があります。これにより、何を死ぬまで守る必要があり、何をダウングレードできるかを分類する必要があります。たとえば、以下を参照できます。ログレベル設定計画:

1. 一般: たとえば、一部のサービスは、ネットワークのジッターやサービスがオンラインであるためにタイムアウトすることがあり、自動的にダウングレードされる可能性があります;

2. 警告: 一部のサービスは、一定期間内の成功率が変動します。一定時間 (95 ～ 100% など) になると、自動的にダウングレードするか手動でダウングレードし、アラームを送信できます;

3. エラー: たとえば、可用性率が 90% 未満であるか、データベース接続が切断されています。プールが枯渇した場合、またはアクセス数が突然増加した場合、システムが耐えられる最大しきい値に達すると、状況に応じて自動的にダウングレードすることも、手動でダウングレードすることもできます;

4. 重大なエラー: たとえば, 特別な理由によりデータが間違っている場合は、緊急の手動ダウングレードが必要です。

サービスのダウングレードの目的は、Redis サービスの障害によってデータベースに雪崩の問題が発生するのを防ぐことです。したがって、重要でないキャッシュされたデータについては、サービスのダウングレード戦略を採用できます。たとえば、Redis に問題がある場合、データベースにクエリを実行する代わりに、デフォルト値をユーザーに直接返すという一般的なアプローチがあります。

キャッシュ ホットスポット キー

キャッシュ内のキー (プロモーション製品など) が特定の時点で期限切れになると、その時点でキーがキャッシュされます。大量の同時リクエストがあります。これらのリクエストは、キャッシュの有効期限が切れていることを検出すると、通常、バックエンド DB からデータをロードしてキャッシュにリセットします。このとき、大量の同時リクエストにより、瞬時にシステムが圧倒される可能性があります。バックエンドDB。

解決策

キャッシュ クエリをロックします。KEY が存在しない場合はロックし、DB をキャッシュにチェックインしてロックを解除します。他のプロセスが存在する場合は、ロックを解除します。ロックがあることを確認します。待って、ロックを解除した後にデータを返すか、DB クエリを入力してください。

プログラミング関連の知識の詳細については、プログラミング ビデオ をご覧ください。 ！

以上がRedis キャッシュ例外が発生した場合はどうすればよいですか?の解き方？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。