目次
Redis におけるブレークダウン、アバランシェ、およびペネトレーションの問題を理解する前に、削除戦略と除去戦略という 2 つの前提条件を理解する必要があります。
1. 削除戦略
削除戦略は、削除時間が設定されているキーに対してのみ有効であり、削除戦略は次の 2 種類に分けられます。
1. 受動的削除: ユーザーがキーにアクセスすると、キーに有効期限が設定されているかどうかが判断され、設定されている場合は有効期限が切れているかどうかが判断され、有効期限が切れている場合は削除されます。
2. アクティブな削除: Redis が自身をポーリングし、有効期限監視のために Redis からランダムに 20 個のキーを取得し、期限切れのキーを削除し、削除されたキーが 25% を超えているかどうかを判断し、超えている場合は、期限切れキー ヘル 25% になるまで上記のプロセスを繰り返します。
2. 排除戦略
排除戦略とは、redis のキャッシュ サイズが設定された制限に達すると、maxmemory によって制御されることを意味します。0 に設定すると、デフォルト値が使用され、32 ビットがデフォルトの 3G になります。
消去戦略には 3 つのタイプがあります。
1、ノエビクション
メモリが使用制限に達し、新しいキーが追加されると、直接失敗が返されます。この排除戦略は、redis がデータベースとして使用される場合にのみ使用され、redis がキャッシュとして使用される場合、この排除戦略は推奨されません。
(Redis はテクノロジー選択時にデータベースとキャッシュの 2 つの役割として使用できますが、データベースとして使用する場合はデータの整合性と正確性が保証されている必要があり、データの損失が発生することはありません。キャッシュとして使用する場合は、データ損失は許容されており、データベースの負荷を軽減するためにデータがホット データであることが保証される必要があります)
2、lru（最近はあまり使われていません）
最近では最も使用されていませんが、redis は完全な lru アルゴリズムではなく近似 lru アルゴリズムを使用し、少数のキーをサンプリングして最適なキーを削除します。設定されたサンプリング データを変更することで、実際の lru アルゴリズムに近づくことができます。構成プロパティは maxmemory-sample です。3.0以降に候補者プールの概念を追加
1) allkeys-lru: lru アルゴリズムを使用して、すべてのキーのキーを削除します。
2) volatile-lru: lru アルゴリズムを使用して、有効期限が設定されたキーのキーを削除します。
3、ランダム
ランダムに削除する
1) allkeys-random: すべてのキーをランダムに削除します。
2) volatile-random: 有効期限を設定してキーをランダムに削除します。
4、ttl(余命短縮)
生存時間が短くなります。これには生存時間が関係するため、生存時間が設定されているキーのみがこの削除戦略 volatile-ttl を持ちます。
5、lfu(最も使用頻度が低い)
最も使用されていないキーはビットマップ タイプのキーを使用し、最初の 16 ビットは使用時間を格納し、最後の 8 ビットはカウンターとして使用されます。lfu-log-factor (カウンタの増加率を調整できます。値が大きいほど、カウンタの増加が遅くなります) と fu-decay-time (分単位の値です。カウンタの減速速度) lfu アルゴリズムを調整する
1) allkeys-lfu: すべてのキーに lfu を使用します。
2) volatile-lfu: 有効期限が設定されたキーには lfu を使用します。
3. キャッシュの内訳
理由: Redis のキーが失敗すると、多数の同時リクエストが同時にそのキーを要求し、キーの有効期限が切れたため、多数の同時リクエストがデータベースに直接アクセスし、機能不全が発生します。
解決策: setnx を使用してロックを実行する複数のリクエストが受信されると、ロックを取得するリクエストがデータベースにクエリを実行し、それを Redis に書き戻します。しかし、ここでいくつかの問題が発生します。
1. ロックが解放される前にロックの取得要求がハングアップすると、デッドロックの問題が発生するため、ロックの有効期限を設定する必要があります。
2. ロックの取得リクエストが有効期限内にビジネスリクエストの処理を完了していない場合、ダーティリードの問題が発生する可能性があり、この場合、ビジネスの処理中に新しいサブスレッドがオープンされる可能性があります。有効期限を確認するリクエスト 監視中、期限が切れる前にリクエストが処理されなかった場合、有効期限は子スレッドを通じて延長されます。
4. キャッシュ雪崩
事故の原因: Redis 内の広範囲のキーに障害が発生し、その後、大量の同時リクエストが受信されました。大規模なキー障害により、大量のリクエストがデータベースに直接アクセスします。違いに注意してください。ブレークダウンから: ブレークダウンはキーに直面していますが、アバランチは複数のキーに直面しています。
解決策: 多数のキーが同時に無効になるのを防ぐために、キーの有効期限をランダムに設定します。ただし、キャッシュ雪崩には特殊な状況、つまりゼロ点障害の問題があり、ビジネス シナリオのデータのバッチでは、指定された時点で全体的な障害が発生する必要があります。ランダムな時間では問題を解決できません。現時点では、ビジネス側でこの状況に対処する必要があります。たとえば、ビジネス側で指定された時間に達したらスレッドを待機する、データの同期に応じて待機時間を指定するなど、特殊な業務処理を実行します。時間経過するか、中間状態で待機し、ユーザーに後でアクセスするよう促します。
5、キャッシュの侵入
理由: 一部のキーは Redis 自体に存在しないため、多数の同時リクエストがこれらの存在しないキーにアクセスし、データベースに直接アクセスします。
解決策: 処理にブルーム フィルターを使用し、事前にブルーム フィルターへのアクセスを許可するキーを追加します。その後、フロントエンド ページがクエリを実行するときに、最初にブルーム フィルターにある場合は別のフィルターでフィルター処理し、その後、ブルーム フィルターを使用します。 redis に存在しない場合、アクセスは続行されますが、ブルーム フィルターに存在せず、redis にも存在しない場合は、悪意のある攻撃を防ぐためにリクエストが拒否されます。
しかし、ブルームフィルターには主に 2 つの問題があります: 1) データの誤判定 (前回の記事で述べました) 2) データを削除できない。削除できない問題には 2 つの解決策があります: 1) 削除する必要があるキーを空にする; 2) カッコー フィルターまたはブルーム フィルターのアップグレード バージョンを選択できます。