緩存設計

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總結一下：

　　

 

 

出處：http://www.cnblogs.com/powerdk/p/7116830.html