【原創】分佈式之緩存擊穿

時間 2019-12-08

原文原文鏈接

什麼是緩存擊穿

在談論緩存擊穿以前，咱們先來回憶下從緩存中加載數據的邏輯，以下圖所示
java

所以，若是黑客每次故意查詢一個在緩存內必然不存在的數據，致使每次請求都要去存儲層去查詢，這樣緩存就失去了意義。若是在大流量下數據庫可能掛掉。這就是緩存擊穿。
場景以下圖所示:
redis

咱們正常人在登陸首頁的時候，都是根據userID來命中數據，然而黑客的目的是破壞你的系統，黑客能夠隨機生成一堆userID,而後將這些請求懟到你的服務器上，這些請求在緩存中不存在，就會穿過緩存，直接懟到數據庫上,從而形成數據庫鏈接異常。數據庫

解決方案

在這裏咱們給出三套解決方案，你們根據項目中的實際狀況，選擇使用.網頁爬蟲

講下述三種方案前，咱們先回憶下redis的setnx方法數組

SETNX key value緩存

將 key 的值設爲 value ，當且僅當 key 不存在。服務器

若給定的 key 已經存在，則 SETNX 不作任何動做。併發

SETNX 是『SET if Not eXists』(若是不存在，則 SET)的簡寫。異步

可用版本：>= 1.0.0maven

時間複雜度： O(1)

返回值： 設置成功，返回 1。設置失敗，返回 0 。

效果以下

redis> EXISTS job                # job 不存在
(integer) 0

redis> SETNX job "programmer"    # job 設置成功
(integer) 1

redis> SETNX job "code-farmer"   # 嘗試覆蓋 job ，失敗
(integer) 0

redis> GET job                   # 沒有被覆蓋
"programmer"

一、使用互斥鎖

該方法是比較廣泛的作法，即，在根據key得到的value值爲空時，先鎖上，再從數據庫加載，加載完畢，釋放鎖。若其餘線程發現獲取鎖失敗，則睡眠50ms後重試。

至於鎖的類型，單機環境用併發包的Lock類型就行，集羣環境則使用分佈式鎖( redis的setnx)

集羣環境的redis的代碼以下所示:

String get(String key) {  
   String value = redis.get(key);  
   if (value  == null) {  
    if (redis.setnx(key_mutex, "1")) {  
        // 3 min timeout to avoid mutex holder crash  
        redis.expire(key_mutex, 3 * 60)  
        value = db.get(key);  
        redis.set(key, value);  
        redis.delete(key_mutex);  
    } else {  
        //其餘線程休息50毫秒後重試  
        Thread.sleep(50);  
        get(key);  
    }  
  }  
}

優勢:

思路簡單
保證一致性

缺點

代碼複雜度增大
存在死鎖的風險

二、異步構建緩存

在這種方案下，構建緩存採起異步策略，會從線程池中取線程來異步構建緩存，從而不會讓全部的請求直接懟到數據庫上。該方案redis本身維護一個timeout，當timeout小於System.currentTimeMillis()時，則進行緩存更新，不然直接返回value值。
集羣環境的redis代碼以下所示:

String get(final String key) {  
        V v = redis.get(key);  
        String value = v.getValue();  
        long timeout = v.getTimeout();  
        if (v.timeout <= System.currentTimeMillis()) {  
            // 異步更新後臺異常執行  
            threadPool.execute(new Runnable() {  
                public void run() {  
                    String keyMutex = "mutex:" + key;  
                    if (redis.setnx(keyMutex, "1")) {  
                        // 3 min timeout to avoid mutex holder crash  
                        redis.expire(keyMutex, 3 * 60);  
                        String dbValue = db.get(key);  
                        redis.set(key, dbValue);  
                        redis.delete(keyMutex);  
                    }  
                }  
            });  
        }  
        return value;  
    }

優勢:

性價最佳，用戶無需等待

缺點

沒法保證緩存一致性

三、布隆過濾器

一、原理

布隆過濾器的巨大用處就是，可以迅速判斷一個元素是否在一個集合中。所以他有以下三個使用場景:

網頁爬蟲對URL的去重，避免爬取相同的URL地址
反垃圾郵件，從數十億個垃圾郵件列表中判斷某郵箱是否垃圾郵箱（同理，垃圾短信）
緩存擊穿，將已存在的緩存放到布隆過濾器中，當黑客訪問不存在的緩存時迅速返回避免緩存及DB掛掉。

OK，接下來咱們來談談布隆過濾器的原理
其內部維護一個全爲0的bit數組，須要說明的是，布隆過濾器有一個誤判率的概念，誤判率越低，則數組越長，所佔空間越大。誤判率越高則數組越小，所佔的空間越小。

假設，根據誤判率，咱們生成一個10位的bit數組，以及2個hash函數（\(f_1,f_2\)），以下圖所示(生成的數組的位數和hash函數的數量，咱們不用去關心是如何生成的，有數學論文進行過專業的證實)。

假設輸入集合爲(\(N_1,N_2\)),通過計算\(f_1(N_1)\)獲得的數值得爲2，\(f_2(N_1)\)獲得的數值爲5，則將數組下標爲2和下表爲5的位置置爲1，以下圖所示

同理，通過計算\(f_1(N_2)\)獲得的數值得爲3，\(f_2(N_2)\)獲得的數值爲6，則將數組下標爲3和下表爲6的位置置爲1，以下圖所示

這個時候，咱們有第三個數\(N_3\)，咱們判斷\(N_3\)在不在集合(\(N_1,N_2\))中，就進行\(f_1(N_3)，f_2(N_3)\)的計算

若值恰巧都位於上圖的紅色位置中，咱們則認爲，\(N_3\)在集合(\(N_1,N_2\))中
若值有一個不位於上圖的紅色位置中，咱們則認爲，\(N_3\)不在集合(\(N_1,N_2\))中

以上就是布隆過濾器的計算原理，下面咱們進行性能測試，

二、性能測試

代碼以下:

(1)新建一個maven工程，引入guava包

<dependencies>  
        <dependency>  
            <groupId>com.google.guava</groupId>  
            <artifactId>guava</artifactId>  
            <version>22.0</version>  
        </dependency>  
    </dependencies>

(2)測試一個元素是否屬於一個百萬元素集合所需耗時

package bloomfilter;

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
import java.nio.charset.Charset;

public class Test {
    private static int size = 1000000;

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

    public static void main(String[] args) {
        for (int i = 0; i < size; i++) {
            bloomFilter.put(i);
        }
        long startTime = System.nanoTime(); // 獲取開始時間
        
        //判斷這一百萬個數中是否包含29999這個數
        if (bloomFilter.mightContain(29999)) {
            System.out.println("命中了");
        }
        long endTime = System.nanoTime();   // 獲取結束時間

        System.out.println("程序運行時間： " + (endTime - startTime) + "納秒");

    }
}

輸出以下所示

命中了
程序運行時間： 219386納秒

也就是說，判斷一個數是否屬於一個百萬級別的集合，只要0.219ms就能夠完成，性能極佳。

(3)誤判率的一些概念

首先，咱們先不對誤判率作顯示的設置，進行一個測試，代碼以下所示

package bloomfilter;

import java.util.ArrayList;
import java.util.List;

import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;

public class Test {
    private static int size = 1000000;

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

    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()); 

    }
}

輸出結果以下

誤判對數量：330

若是上述代碼所示，咱們故意取10000個不在過濾器裏的值，卻還有330個被認爲在過濾器裏，這說明了誤判率爲0.03.即，在不作任何設置的狀況下，默認的誤判率爲0.03。
下面上源碼來證實：

接下來咱們來看一下，誤判率爲0.03時，底層維護的bit數組的長度以下圖所示

將bloomfilter的構造方法改成

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

即，此時誤判率爲0.01。在這種狀況下，底層維護的bit數組的長度以下圖所示

因而可知，誤判率越低，則底層維護的數組越長，佔用空間越大。所以，誤判率實際取值，根據服務器所可以承受的負載來決定，不是拍腦殼瞎想的。

三、實際使用

redis僞代碼以下所示

String get(String key) {  
   String value = redis.get(key);  
   if (value  == null) {  
        if(!bloomfilter.mightContain(key)){
            return null;
        }else{
           value = db.get(key);  
           redis.set(key, value);  
        }
    } 
    return value；
}

優勢: