為什么使用緩存

在高并發(fā)請求時，我們會頻繁提到使用緩存技術(shù)，最直接的原因是，磁盤IO及網(wǎng)絡(luò)開銷是直接請求內(nèi)存IO的千百上千倍

做個簡單計算，如果我們需要某個數(shù)據(jù)，該數(shù)據(jù)從數(shù)據(jù)庫磁盤讀出來需要0.0045S，經(jīng)過網(wǎng)絡(luò)請求傳輸需要0.0005S，那么每個請求完成最少需要0.005S，該數(shù)據(jù)服務(wù)器每秒最多只能響應(yīng)200個請求，而如果該數(shù)據(jù)存于本機內(nèi)存里，讀出來只需要100us，那么每秒能夠響應(yīng)10000個請求。通過將數(shù)據(jù)存儲到離CPU更近的未位置，減少數(shù)據(jù)傳輸時間，提高處理效率，這就是緩存的意義。

什么場景下適合使用緩存

• 讀密集型的應(yīng)用

• 存在熱數(shù)據(jù)的應(yīng)用

• 對響應(yīng)時效要求高的應(yīng)用

• 對一致性要求不嚴格的場景

• 需要實現(xiàn)分布式鎖的時候

什么場景下不適合使用緩存

• 對一致性要求嚴格的場景

• 更新頻繁，更新數(shù)據(jù)頻率過高的場景，頻繁同步緩存中的數(shù)據(jù)所花費的代價可能比不使用緩存的代價還要高

• 讀少的場景，對于讀少的系統(tǒng)而言，使用緩存就完全沒有意義了，比較使用緩存是為了讀取數(shù)據(jù)更高效

緩存收益成本對比

收益

1. 加速讀寫。因為緩存通常都是全內(nèi)存的系統(tǒng)，通過緩存的使用可以有效提高用戶的訪問速度同時優(yōu)化用戶體驗。

2. 降低后端負載。通過添加緩存，如果程序沒有什么問題，在命中率還可以的情況下，可以幫助后端減少訪問量和復(fù)雜計算，很大程度降低了后端的負載。

成本

1. 數(shù)據(jù)不一致性。無論設(shè)計做的多么好，緩存數(shù)據(jù)與真實數(shù)據(jù)源一定存在著一定時間窗口的數(shù)據(jù)不一致性

2. 代碼維護成本。有緩存后，代碼就會在原數(shù)據(jù)源基礎(chǔ)上加入緩存的相關(guān)代碼，例如原來只是一些sql，現(xiàn)在要加入緩存，必然增加代碼維護成本。

3. 架構(gòu)復(fù)雜度。有緩存后，需要專門的管理人員來維護主從緩存系統(tǒng)，同時也增加了架構(gòu)的復(fù)雜度和維護成本。

高并發(fā)場景下帶來的常見問題

在高并發(fā)場景下，緩存主要會帶來下面幾個問題:

1.緩存一致性

2.緩存并發(fā)（緩存擊穿）

3.緩存穿透

4.緩存雪崩（緩存失效）

打個比方，你是個很有錢的人，開滿了百度云，騰訊視頻各種雜七雜八的會員，但是你就是沒有netflix的會員，然后你把這些賬號和密碼發(fā)布到一個你自己做的網(wǎng)站上，然后你有一個朋友每過十秒鐘就查詢你的網(wǎng)站，發(fā)現(xiàn)你的網(wǎng)站沒有Netflix的會員后打電話向你要。你就相當(dāng)于是個數(shù)據(jù)庫，網(wǎng)站就是Redis。這就是緩存穿透。

大家都喜歡看騰訊視頻上 周星馳的《喜劇之王》 ，但是你的會員突然到期了，大家在你的網(wǎng)站上看不到騰訊視頻的賬號，紛紛打電話向你詢問，這就是緩存擊穿

你的各種會員突然同一時間都失效了，那這就是緩存雪崩了。

下面一一介紹！

緩存一致性問題

當(dāng)數(shù)據(jù)時效性要求很高時，需要保證緩存中的數(shù)據(jù)與數(shù)據(jù)庫中的保持一致，而且需要保證緩存節(jié)點和副本中的數(shù)據(jù)也保持一致，不能出現(xiàn)差異現(xiàn)象。這就比較依賴緩存的過期和更新策略。一般會在數(shù)據(jù)發(fā)生更改的時，主動更新緩存中的數(shù)據(jù)或者移除對應(yīng)的緩存。

下圖情況都會導(dǎo)致數(shù)據(jù)一致性問題  

緩存擊穿問題

對于一些設(shè)置了過期時間的key，可能這些key會在某些時間點被超高并發(fā)地訪問，是一種非常“熱點”的數(shù)據(jù)。這個時候，需要考慮緩存被“擊穿”的問題，和緩存雪崩的區(qū)別在于這里針對某一key緩存，而緩存雪崩則是很多key。

如圖所示： 

解決方案:

業(yè)界比較常用的做法，是使用mutex（互斥鎖）。

1.使用互斥鎖(mutex key)

該方案思路比較簡單，就是只讓一個線程構(gòu)建緩存，其他線程等待構(gòu)建緩存的線程執(zhí)行完，重新從緩存獲取數(shù)據(jù)就可以

如果是單機可以用synchronized或者lock來處理，如果是分布式環(huán)境可以用分布式鎖（redis的setnx, zookeeper的添加節(jié)點操作）

redis偽代碼如下:

public String get(String key) { 
        String value = storeClient.get(key); 
        StoreKey key_mutex = new MutexStoreKey(key); 
        if (value == null) {//代表緩存值過期 
            //設(shè)置2min的超時，防止刪除緩存操作失敗的時候，下次緩存過期一直不能獲取DB數(shù)據(jù) 
            if (storeClient.setnx(key_mutex, 1, 2 * 60)) {  //代表設(shè)置成功 
                value = db.get(key); 
                storeClient.set(key, value, 3 * 3600); 
                storeClient.delete(key_mutex); 
            } else { 
                sleep(1000);  //這個時候代表同時候的其他線程已經(jīng)獲取DB數(shù)據(jù)并回設(shè)到緩存了，這時候重試獲取緩存值即可 
                return get(key);  //重試 
            } 
        } 
        return value; 
    } 

2.“提前”使用互斥鎖(mutex key)

即在value內(nèi)部設(shè)置1個超時值(timeout1)，timeout1比實際的redis timeout(timeout2)小。

當(dāng)從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過期時候，馬上延長timeout1并重新設(shè)置到cache。然后再從數(shù)據(jù)庫加載數(shù)據(jù)并設(shè)置到cache中。

方案2和方案1的區(qū)別在于，如果緩存有數(shù)據(jù)，但是已經(jīng)過期，會提前使用互斥鎖，查詢DB最新數(shù)據(jù)再緩存起來

偽代碼如下，注意代碼else里面的邏輯。

public String get(String key) { 
        MutexDTO value = storeClient.get(key); 
        StoreKey key_mutex = new MutexStoreKey(key); 
        if (value == null) { 
            if (storeClient.setnx(key_mutex, 3 * 60 * 1000)) { 
                value = db.get(key); 
                storeClient.set(key, value); 
                storeClient.delete(key_mutex); 
            } else { 
                sleep(50); 
                get(key); 
            } 
        } else { 
            if (value.getTimeout() <= System.currentTimeMillis()) { 
                if (storeClient.setnx(key_mutex, 3 * 60 * 1000)) { 
                    value.setTimeout(value.getTimeout() + 3 * 60 * 1000); 
                    storeClient.set(key, value, 3 * 3600 * 2); 
 
                    value = db.get(key);//獲取最近DB更新數(shù)據(jù) 
                    value.setTimeout(value.getTimeout() + 3 * 60 * 1000); 
                    storeClient.set(key, value, 3 * 3600 * 2); 
                    storeClient.delete(key_mutex); 
                } else { 
                    sleep(50); 
                    get(key); 
                } 
            } 
        } 
         return value.getValue(); 
    } 

3.緩存”永不過期“

這里的“永遠不過期”包含兩層意思:

• 從redis上看，不設(shè)置過期時間，這就保證了，不會出現(xiàn)熱點key過期問題，也就是“物理”不過期。

• 從功能上看，如果不過期，那不就成靜態(tài)的了嗎？所以我們把過期時間存在key對應(yīng)的value里，如果發(fā)現(xiàn)要過期了，通過一個后臺的異步線程進行緩存的構(gòu)建，也就是“邏輯”過期。

public String get(String key) { 
        MutexDTO mutexDTO = storeClient.get(key); 
        String value = mutexDTO.getValue(); 
        if (mutexDTO.getTimeout() <= System.currentTimeMillis()) { 
            ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();// 異步更新后臺異常執(zhí)行 
            singleThreadExecutor.execute(new Runnable() { 
                public void run() { 
                    StoreKey mutexKey = new MutexStoreKey(key); 
                    if (storeClient.setnx(mutexKey, "1")) { 
                        storeClient.expire(mutexKey, 3 * 60); 
                        String dbValue = db.get(key); 
                        storeClient.set(key, dbValue); 
                        storeClient.delete(mutexKey); 
                    } 
                } 
            }); 
        } 
        return value; 
    } 

三種方法如下比較：

緩存穿透問題

緩存穿透是指查詢一個一定不存在的數(shù)據(jù)，由于緩存是不命中時被動寫的，并且出于容錯考慮，如果從存儲層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個不存在的數(shù)據(jù)每次請求都要到存儲層去查詢，失去了緩存的意義。

在流量大時，要是DB無法承受瞬間流量沖擊，DB可能就掛了。

如圖所示：  

解決方案：

有多種方法可以有效解決緩存穿透問題，一種比較簡單粗暴的方法采用緩存空數(shù)據(jù)，如果一個查詢返回的數(shù)據(jù)為空（數(shù)據(jù)庫中不存在該數(shù)據(jù)），仍然把這個空結(jié)果進行緩存（過期時間一般較短）。

另一種方法則是采用常用的布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。

1.緩存空數(shù)據(jù)

當(dāng)Client請求MISS后，仍然將空對象保留到Cache中（可能是保留一段時間，具體問題具體分析），下次新的Request（同一個key）將會從Cache中獲取到數(shù)據(jù)，保護了后端的DB。偽代碼如下：

public class CacheNullService { 
    private Cache cache = new Cache(); 
    private Storage storage = new Storage(); 
    /** 
     * 模擬正常模式  
     * @param key 
     * @return 
     */ 
    public String getNormal(String key) { 
        // 從緩存中獲取數(shù)據(jù)   
        String cacheValue = cache.get(key); 
        // 緩存為空   
        if (StringUtils.isBlank(cacheValue)) { 
            // 從存儲中獲取   
            String storageValue = storage.get(key); 
            // 如果存儲數(shù)據(jù)不為空,將存儲的值設(shè)置到緩存   
            if (StringUtils.isNotBlank(storageValue)) { 
                cache.set(key, storageValue); 
            } 
            return storageValue; 
        } else { 
            // 緩存非空   
            return cacheValue; 
        } 
    } 
    /** 
     * 模擬防穿透模式  
     * @param key 
     * @return 
     */ 
    public String getPassThrough(String key) { 
        // 從緩存中獲取數(shù)據(jù)   
        String cacheValue = cache.get(key); 
        // 緩存為空   
        if (StringUtils.isBlank(cacheValue)) { 
            // 從存儲中獲取   
            String storageValue = storage.get(key); 
            cache.set(key, storageValue); 
            // 如果存儲數(shù)據(jù)為空，需要設(shè)置一個過期時間(300秒)   
            if (StringUtils.isBlank(storageValue)) { 
                cache.expire(key, 60 * 5); 
            } 
            return storageValue; 
        } else { 
            // 緩存非空   
            return cacheValue; 
        } 
    } 
} 

2.布隆過濾器

BloomFilter 是一個非常有意思的數(shù)據(jù)結(jié)構(gòu)，不僅僅可以擋住非法 key 攻擊，還可以低成本、高性能地對海量數(shù)據(jù)進行判斷，比如一個系統(tǒng)有數(shù)億用戶和百億級新聞 feed，就可以用 BloomFilter 來判斷某個用戶是否閱讀某條新聞 feed

在訪問所有資源(cache, DB)之前，將存在的key用布隆過濾器提前保存起來，做第一層攔截。算法的簡單圖解如下: 

 用布隆過濾器實際只需要判斷客戶端傳過來的userCode是否存在就可以，圖中的hash1,hash2,hash3分別代表三種hash算法，不同的userCode對應(yīng)著不同的數(shù)據(jù)位，當(dāng)需要校驗的時候，判斷每一種算法的得出來的byte位是否相同，只要一位不同，那么我們可以認為這個userCode不存在。

一般BloomFilter 要緩存全量的 key，這就要求全量的 key 數(shù)量不大，10 億條數(shù)據(jù)以內(nèi)最佳，因為 10 億條數(shù)據(jù)大概要占用 1.2 GB 的內(nèi)存。也可以用 BloomFilter 緩存非法 key，每次發(fā)現(xiàn)一個 key 是不存在的非法 key，就記錄到 BloomFilter 中，這種記錄方案，會導(dǎo)致 BloomFilter 存儲的 key 持續(xù)高速增長，為了避免記錄 key 太多而導(dǎo)致誤判率增大，需要定期清零處理

布隆使用案例如下:

import com.google.common.base.Charsets; 
import com.google.common.hash.BloomFilter; 
import com.google.common.hash.Funnels; 
 
import java.util.*; 
 
public class BFDemo { 
 
    private static final int insertions = 1000000;//100W 
 
    public static void main(String[] args) { 
        BloomFilter bf = BloomFilter.create(Funnels.stringFunnel(Charsets.UTF_8), insertions); 
        Set sets = new HashSet(insertions); 
        List<String> lists = new ArrayList(insertions); 
        for (int i = 0; i < insertions; i++) { 
            String uuid = UUID.randomUUID().toString(); 
            bf.put(uuid); 
            sets.add(uuid); 
            lists.add(uuid); 
        } 
        int wrong = 0; 
        int right = 0; 
        for (int i = 0; i < 10000; i++) { 
            String test = i % 100 == 0 ? lists.get(i / 100) : UUID.randomUUID().toString();  //隨機生成1W字符串 
            if (bf.mightContain(test)) { 
                if (sets.contains(test)) { 
                    right++; 
                } else { 
                    wrong++; 
                } 
            } 
        } 
        System.out.println("========right=======" + right); 
        System.out.println("========wrong=======" + wrong); 
    } 
 
} 

上文中提到的兩種方法，比較：

緩存雪崩問題

緩存雪崩一般是由兩個原因?qū)е碌?/h4>

第一個原因是：緩存中有大量數(shù)據(jù)同時過期，導(dǎo)致大量請求無法得到處理。

如圖所示： 

 

 

 

解決方案：

設(shè)計不同的過期時間

我們可以避免給大量的數(shù)據(jù)設(shè)置相同的過期時間。如果業(yè)務(wù)層的確要求有些數(shù)據(jù)同時失效，你可以在用EXPIRE命令給每個數(shù)據(jù)設(shè)置過期時間時，給這些數(shù)據(jù)的過期時間增加一個較小的隨機數(shù)（例如，隨機增加1~3分鐘），這樣一來，不同數(shù)據(jù)的過期時間有所差別，但差別又不會太大，既避免了大量數(shù)據(jù)同時過期，同時也保證了這些數(shù)據(jù)基本在相近的時間失效，仍然能滿足業(yè)務(wù)需求

服務(wù)降級處理

發(fā)生緩存雪崩時，針對不同的數(shù)據(jù)采取不同的處理方式。

• 當(dāng)業(yè)務(wù)應(yīng)用訪問的是非核心數(shù)據(jù)時，暫時停止從緩存中查詢這些數(shù)據(jù)，而是直接返回預(yù)定義信息、空值或是錯誤信息；

• 當(dāng)業(yè)務(wù)應(yīng)用訪問的是核心數(shù)據(jù)時，仍然允許查詢緩存，如果緩存缺失，也可以繼續(xù)通過數(shù)據(jù)庫讀取。

對緩存增加多個副本

緩存異?；蛘埱?miss 后，再讀取其他緩存副本，而且多個緩存副本盡量部署在不同機架，從而確保在任何情況下，緩存系統(tǒng)都會正常對外提供服務(wù)

對緩存體系進行實時監(jiān)控

當(dāng)請求訪問的慢速比超過閥值時，及時報警，通過機器替換、服務(wù)替換進行及時恢復(fù)；也可以通過各種自動故障轉(zhuǎn)移策略，自動關(guān)閉異常接口、停止邊緣服務(wù)、停止部分非核心功能措施，確保在極端場景下，核心功能的正常運行。

第二個原因是：

如果Cache層由于某些原因(宕機、cache服務(wù)掛了或者不響應(yīng)了)整體crash掉了，也就意味著所有的請求都會達到DB層，所有DB調(diào)用量會暴增，所以它有點扛不住了，甚至也會掛掉。

如圖所示： 

 雪崩過后緩存已經(jīng)crash，解決方案無非是讓DB能承受更大數(shù)據(jù)壓力，我們可以DB擴容解決，但不是長久之計，最好解決辦法是如何預(yù)防緩存雪崩。

如何預(yù)防我們可以從以下方面入手:

保證Cache服務(wù)高可用性。

如果我們的cache也是高可用的，即使個別實例掛掉了，影響不會很大（主從切換或者可能會有部分流量到了后端），實現(xiàn)自動化運維。

例如:memcache的一致性hash、redis的sentinel和cluster機制

依賴隔離組件為后端限流。

其實無論是cache或者是mysql、hbase、甚至別人的RPC都會出現(xiàn)問題，我們可以將這些視同為資源，作為并發(fā)量較大的系統(tǒng)，假如有一個資源不可訪問了，即使設(shè)置了超時時間，依然會hold住所有線程，造成其他資源和接口也不可以訪問。

提前演練預(yù)估。

在項目上線前，通過演練，觀察cache crash后，整體系統(tǒng)和DB的負載，提前做好預(yù)案。