キャッシュペネトレーションとは、キャッシュまたはデータベースにないデータに常にアクセスしているユーザーの存在を指します。これにより、データベースに過度の圧力がかかり、サービス処理の遅延やデータベースのクラッシュなどの問題が発生する可能性があります。たとえば、発信元は、IDが「-1」のデータ、または存在しない特に大きなIDのデータです。この時点でのユーザーは攻撃者である可能性があります。

解決

多くの解決策がありますが、一般的には次の方法があります

1.インターフェース層の検証

インターフェース層は、ユーザー認証検証、基本検証のid、id <= 0の直接傍受などの検証を追加します。実装は比較的単純ですが、要求の一部しか傍受できません。

2.空のオブジェクトをキャッシュする

キャッシュから取得できないデータはデータベースで取得されません。このとき、キーと値のペアをキー/ nullとして書き込むこともでき、キャッシュの有効時間を30秒などの短いポイントに設定できます（長すぎると正常な状態になります）使用できません）。これにより、攻撃ユーザーが同じIDブルートフォース攻撃を繰り返し使用するのを防ぎ、バックエンドデータソースを保護できます。

問題があります

1. null値をキャッシュできる場合、多くのnullキーが存在する可能性があるため、キャッシュはより多くのキーを格納するためにより多くのスペースを必要とすることを意味します。

2.有効期限がnull値に設定されている場合でも、一定期間、キャッシュレイヤーとストレージレイヤーのデータ間に不整合のウィンドウが存在し、整合性を維持する必要のあるビジネスに影響を与えます。

3.ブルームフィルター

ブルームフィルターはビットベクトルまたはビットです。値をブルームフィルターにマップする場合、複数の異なるハッシュ関数を使用して複数のハッシュ値を生成し、生成された各ハッシュ値を組み合わせる必要があります。指摘されたビットは1に設定されます。

異なる単語に対応するビット位置は同じであることがわかります。多くの単語がある場合、ほとんどのビット位置は1になります。このとき、クエリ製品1は位置1に対応する場合があり、単語製品1のみを説明できます。存在する可能性がありますが、必ずしも存在するとは限りません。

ブルームフィルターの優れた使い方は、要素がセットに含まれているかどうかをすばやく判断できることです。ヒットが存在する可能性がありますが、ミスは絶対にありません！

たとえば、Gavaが提供するブルームフィルターでは、次のプログラムは1000000データを生成してブルームフィルターを初期化でき、フィルターの誤判定率は3％で、ブルームフィルターに存在しない10000の値を意図的に取得して出力します誤判定の数は300です。

public class BloomFilterTest {
    private static int size = 1000000;

    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.03);

    public static void main(String[] args) {
        for (int i = 0; i < size; i++) {
            bloomFilter.put(i);
        }

        List<Integer> list = new ArrayList<Integer>(1000);
        //故意取10000个不在过滤器里的值，看看有多少个会被认为在过滤器里
        for (int i = size + 10000; i < size + 20000; i++) {
            if (bloomFilter.mightContain(i)) {
                list.add(i);
            }
        }
        System.out.println("误判的数量：" + list.size());
    }
}

使用するシーン

Webクローラーは、同じURLアドレスのクロールを回避するためにURLの重複を排除します
アンチスパム、メールボックスが何十億ものスパムリストからのスパムかどうかを判断します（同様に、スパムメッセージ）。
キャッシュの侵入、可能なすべてのデータキャッシュをブルームフィルターに入れ、ハッカーが存在しないキャッシュにアクセスすると、キャッシュとDBのハングを回避するためにすばやく戻ります。

利点

シンプルなアイデア
一貫性を確保
強力なパフォーマンス

不利益

コードの複雑さの増加
キャッシュされたキーを格納するために追加のコレクションを維持する必要がある
ブルームフィルターは削除操作をサポートしていません
ブルームフィルターの初期化とフィルターの更新はより複雑です

次のコードは、Bloomフィルターを使用して、値がredisで使用できない場合にデータベースにデータが存在するかどうかを判別し、データベースアクセスIOを削減します。参照用に提供できます。

第三に、キャッシュの故障の問題

キャッシュの浸透すべての学生は、2つが同じものであると考えて、キャッシュの浸透と混同することがよくあります。面接でそういう子供靴に出会うことが多いから

キャッシュの内訳とは、キャッシュにはデータがなく、データベースにデータがあることを意味します（通常、キャッシュ時間の期限が切れたとき）。現時点では、非常に多くの同時ユーザーが存在し、同時にデータが読み取りキャッシュで読み取られないため、データベースにアクセスしてデータをフェッチし、データベースに圧力をかけます。瞬時に増加し、過剰な圧力が発生します。

解決

1.ホットスポットデータを無期限に設定します。

うーん...シーンはありますが、科学的なものではありません。

2.ミューテックスロック

キャッシュからデータがフェッチされない場合、大量のデータがデータベースに到達するのを防ぐために、ミューテックスロックを追加することで現在のデータを制限できます。同時に、同じデータに対する1つのリクエストのみがデータベースに入力してデータを取得できます。データベースからデータを取得すると、データはredisに書き戻され、他のブロックされたリクエストはredisからデータを取得します。データベースの負荷を軽減するため。

mutex参照コードは次のとおりです。

第4に、キャッシュなだれ

キャッシュ雪崩とは、有効期限までのキャッシュ内の大量のデータ、またはキャッシュレイヤーの障害が利用できなくなり、クエリデータの量が膨大になることを指します。リクエストはキャッシュを直接バイパスし、データベースを直接リクエストするため、データベースに過度の圧力がかかり、さらにはダウンタイムが発生します。

解決

1. Redisは高可用性です

このアイデアの意味は、redisがハングする可能性があるため、いくつかのredisを追加して、1つがハングした後、他のメンバーが引き続き動作できるようにすることです。redisの高可用性デプロイメントとセンチネルメカニズムを参照できます。これについては後で話します

2.有効期限は均等に配分されます

redisの有効期限を一定の時間に設定しないでください。たとえば、有効期限は1時間であり、ランダムに5分ずつ増減して、データが同時に期限切れにならないようにすることができます。

5、いくつかの失敗の比較

障害のタイプ	Redisにはデータがありますか	データベースにデータが存在するかどうか	キーの有効期限
キャッシュ浸透	番号	番号	番号
キャッシュの内訳	番号	はい	番号
キャッシュなだれ	番号	はい	多数のキーが同時に期限切れになるか、キャッシュレイヤーが使用できなくなります

失敗の種類と表現の仕方に応じて表を掲載し、皆さまの理解を深めます。

知らないRedis 2つ-キャッシュ浸透とキャッシュなだれ問題と解決策

1.キャッシュの使い方

2.キャッシュ侵入問題

解決