緩存設計

1.前言&基本介紹

　　　　在原始的系統架構中，我們都由程序直接連接DB，隨着業務的進一步開展，DB的壓力越來越大，為了緩解DB的這一壓力，我們引入了緩存，在程序連接DB中加入緩存層，

從而減輕數據庫壓力，而且緩存一般存在於內存中，相比於存在硬盤中的DB在讀取速度上絕對是比DB高幾個等級。下面我們來簡單聊聊關於緩存幾個東西

  

2.緩存的優缺點

　　　　緩存的優點就是“快”，一個快字基本能概括了。如上文說的加速讀寫，分流對數據庫的壓力，歸根結底就是對快字的應用及其本身，缺點主要是如下三點：

　　　　　　1.數據不一致性：DB的數據與緩存中的數據不一致

　　　　　　2.開發成本：需要同時處理緩存層跟DB層的邏輯，增加了開發成本

　　　　　　3.維護成本：例如需要對緩存層進行一個監控，增加了運維的成本

 

3.緩存更新策略

 　　　　在上面中我們說到數據不一致性，一般來說緩存也是需要有生命周期的，需要被更新或者刪除，這樣才能保持緩存的可控性，在緩存更新中有如下三點：

　　　　　　1.LR(F)U/FIFO算法刪除：簡單來說就是按照隊列的形式對不常用的緩存進行刪除，鏈表的形式來實現，具體可點這里http://blog.csdn.net/maddemon/article/details/6650703

 

　　　　　　2.超時刪除：在設置緩存的時候可以設置過期時間，在時間到期之后自動刪除。在使用這個的時候，最好還是確保緩存數據跟數據庫數據不一致的時候業務能容忍，還是存在一致性的問題

 

　　　　　　3.主動更新：應用於對數據一致性要求高的，但最好還是需要保證更新的准確性。假如對實時性要求不高的，還是根據超時刪除吧

 

4.緩存粒度

　　　　假設一張用戶表有20個字段，那是否需要將全部字段都放到緩存中？這就涉及到一個粒度的問題！數據字段放少了，就會出現了不通用的問題；數據字段放多了，空間占用也多，序列化跟反序

列化消耗的性能更多了。在粒度這個問題上還是需要根據通用性，代碼維護，性能跟空間占用這幾點上進行考慮， 簡單來說就是靠經驗了

 

5.緩存穿透

 　　　　　緩存穿透指的是查詢一個不存在的數據，DB跟緩存都不會命中的數據。這樣的話每次查詢都會到DB層中查詢，DB層負載加大還有可能造成死機，這樣緩存就失去了保護DB層的意義。出現這種情況有兩種：1.攻擊，爬蟲的大量請求；2.業務自身有問題。現在基本流行的解決方案有以下兩種：

 　　　　　　5.1 緩存空對象，當DB層也查不到數據的時候，緩存一個null值進緩存，這樣下一次的話就直接從緩存中讀取，保護了后端。不過這種帶來的后果是緩存了更多的鍵，需要更多的空間，而且不可控性增加

 

　　　　　　5.2布隆過濾器攔截，它利用位數組很簡潔地表示一個集合，並能判斷一個元素是否屬於這個集合。這樣在查詢緩存之前先去過濾器中查詢緩存是否有存在該key。不過這個適合於數據量固定，實時性低的應用中，因為要維護這一個過濾器。

 

6.雪崩優化

　　　　指的是原先的緩存層承載了大量的請求，有效的保護了DB層，但是假如緩存層炸了，那所有的請求都直接穿透到DB層，會容易造成DB層也炸了。就這個問題一直沒有一個很完美的解決方案，可以從下列兩個方面進行思考：

　　　　　　6.1.保證緩存層的高可用(HA)，例如redis的Sentinel跟Cluster都實現了高可用（在windows10下跑這個sentinel，偶爾會出現節點掛了但是sentinel沒反應過來的情況，還是linux穩定一點）

 

　　　　　　6.2.提前演練，這個類似與實驗設計，模擬某一層掛了的處理情況

 

7.總結

　　最后用Xmind總結一下：