Redis處理高并發(fā)之布隆過濾器詳解

更新時間：2022年12月29日 14:42:43 作者：Lxlxxx

這篇文章主要為大家介紹了Redis處理高并發(fā)之布隆過濾器詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

隨著我們業(yè)務開發(fā)越來越來大，并染請求就會越來越多，那么我們的項目的壓力就會越來越大，基本都會使用緩存，除本地緩存，還會用到redis緩存，但是你以為使用緩存就沒啥問題了么，那肯定不是的，使用了緩存又會出現(xiàn)新的問題，比如，緩存的key失效導致大量的請求到數(shù)據(jù)庫，大量的讀請求瞬間到達了數(shù)據(jù)庫，cpu的使用率爆增，導致數(shù)據(jù)庫都可能掛掉，這種情況下我們就要考慮使用redis的布隆過濾器了。

緩存穿透、擊穿、雪崩

首先我們從緩存會出現(xiàn)的幾種問題，來進行分析，在高并發(fā)的場景下如果出現(xiàn)這種情況，我們應該如何解決。

正常情況下，我們的web應用會先去請求緩存服務，如果緩存命中，那么就去拿緩存里面的數(shù)據(jù)，返回結(jié)果給應用，

緩存穿透

緩存穿透與緩存雪崩和緩存擊穿還是不一樣的，雪崩和擊穿的情況下，數(shù)據(jù)庫的數(shù)據(jù)都是真正常的，可以去請求數(shù)據(jù)庫獲取數(shù)據(jù)，只是緩存層出現(xiàn)問題，等待緩存恢復了，就會減輕數(shù)據(jù)庫的壓力。而緩存透不一樣的就是，緩存和數(shù)據(jù)庫都沒有要請求的數(shù)據(jù)，大量的請求來了，數(shù)據(jù)庫的壓力很大。

出現(xiàn)情況

數(shù)據(jù)庫數(shù)據(jù)被大量清除，導致訪問不到
黑客惡意攻擊

常見的解決方案

redis緩存空值，請求不到的時候返回給應用空值。
使用布隆過濾器，把數(shù)據(jù)庫的一部分數(shù)據(jù)hash到布隆過濾器里，在請求數(shù)據(jù)庫之前先去布隆過濾器里篩選到一部分請求，判斷數(shù)據(jù)是否存在，避免直接去訪問數(shù)據(jù)庫。

緩存擊穿

出現(xiàn)情況

大量熱點數(shù)據(jù)庫過期，導致無法從緩存獲取到數(shù)據(jù)，大量請求數(shù)據(jù)庫也無法返回書就

解決方案

加鎖，保證同一時間內(nèi)，只允許有一個線程去更新緩存，等鎖釋放后在重新去請求緩存。
熱點數(shù)據(jù)不去設置過期時間，如果要設置過期時間，在過期的時候通知后臺去更新緩存的過期時間。

緩存雪崩

大量緩存在同一時間失效，導致大量請求進入數(shù)據(jù)庫
redis故障宕機，導致緩存不能使用。

解決方案

同上加鎖
給緩存的過期時間加入隨機數(shù)，保證緩存不會在同一時間同時失效。
副本key策略，就是對于一個key，在它的基礎上在設置一個key，它們的value都是一樣的，只不過一個設置過期時間、一個不設置過期時間，相當于給key做了個副本，只不過在更新緩存的時候，副本key也是要更新的，避免出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象。

布隆過濾器 Bloom filter

前面提到過布隆過濾器在請求比較高的時候，可以幫助我們抵擋一部分請求，從而減輕數(shù)據(jù)庫的壓力，布隆過濾器的數(shù)據(jù)結(jié)構是一個二進制的bit向量，或者說是一個bit數(shù)組，它相對于list、set、map這些集合，它占用的空間更少，不足之處處就是返回的結(jié)果會有一定概率的誤差。

public static void main(String[] args) {
    int size = 1_000_000;
    BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size);
    for (int i = 0; i < size; i++) {
        bloomFilter.put(i);
    }
    for (int i = 0; i < size; i++) {
        if (!bloomFilter.mightContain(i)) {
            System.out.println("有漏網(wǎng)之魚");
        }
    }
    List<Integer> list = new ArrayList<>(1000);
    for (int i = size + 10000; i < size + 20000; i++) {
        if (bloomFilter.mightContain(i)) {
            list.add(i);
        }
    }
    System.out.println("有誤差的數(shù)量：" + list.size());
}

確實有誤差的數(shù)量，但是誤差量不大，追求效率的同時只是犧牲一點誤差了。