作者 陳彩華
文章轉載交流請聯絡 caison@aliyun.com
複製程式碼承接上一篇《理解分散式系統中的快取架構(上)》，介紹了大型分散式系統中快取的相關理論，常見的快取元件以及應用場景，本文主要介紹快取架構設計常見問題以及解決方案，業界案例。
1 分層快取架構設計
2 快取帶來的複雜度問題
常見的問題主要包括
- 資料一致性
- 快取穿透
- 快取雪崩
- 快取高可用
- 快取熱點 下面逐一介紹分析這些問題以及相應的解決方案。
資料一致性
因為快取屬於持久化資料的一個副本，因此不可避免的會出現資料不一致問題。導致髒讀或讀不到資料的情況。資料不一致，一般是因為網路不穩定或節點故障導致
問題出現的常見3個場景以及解決方案：
快取穿透
快取一般是Key，value方式存在，當某一個Key不存在時會查詢資料庫，假如這個Key，一直不存在，則會頻繁的請求資料庫，對資料庫造成訪問壓力。
主要解決方案：
- 對結果為空的資料也進行快取，當此key有資料後，清理快取
- 一定不存在的key，採用布隆過濾器，建立一個大的Bitmap中，查詢時通過該bitmap過濾
快取雪崩
快取高可用
快取是否高可用，需要根據實際的場景而定，並不是所有業務都要求快取高可用，需要結合具體業務，具體情況進行方案設計，例如臨界點是是否對後端的資料庫造成影響。
主要解決方案：
- 分散式：實現資料的海量快取
- 複製：實現快取資料節點的高可用
快取熱點
一些特別熱點的資料，高併發訪問同一份快取資料，導致快取伺服器壓力過大。
解決：複製多份快取副本，把請求分散到多個快取伺服器上，減輕快取熱點導致的單臺快取伺服器壓力
3 業界案例
案例主要參考新浪微博陳波的技術分享
技術挑戰
Feed快取架構圖
架構特點
新浪微博把SSD應用在分散式快取場景中，將傳統的Redis/MC + Mysql方式，擴充套件為 Redis/MC + SSD Cache + Mysql方式，SSD Cache作為L2快取使用，第一降低了MC/Redis成本過高，容量小的問題，也解決了穿透DB帶來的資料庫訪問壓力
主要在資料架構、效能、儲存成本、服務化等不同方面進行了優化增強
(本文同時發表於作者個人部落格 www.jianshu.com/u/ced6b70c7…)