1.前言&基本介紹

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

從而減輕資料庫壓力，而且快取一般存在於記憶體中，相比於存在硬碟中的 DB在讀取速度上絕對是比DB高几個等級。下面我們來簡單聊聊關於快取幾個東西

2.快取的優缺點

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

　　　　　　 1.資料不一致性：DB的資料與快取中的資料不一致

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

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

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

　　　　　　 1.LR(F)U/FIFO演算法刪除：簡單來說就是按照佇列的形式對不常用的快取進行刪除，連結串列的形式來實現，

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

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

　　　　假設一張使用者表有 20個欄位，那是否需要將全部欄位都放到快取中？這就涉及到一個粒度的問題！資料欄位放少了，就會出現了不通用的問題；資料欄位放多了，空間佔用也多，序列化跟反序

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

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

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

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

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

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

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

　　最後用 Xmind總結一下：