深入理解分散式系統中的快取架構(下)

承接上一篇《理解分散式系統中的快取架構(上)》，介紹了大型分散式系統中快取的相關理論，常見的快取元件以及應用場景，本文主要介紹快取架構設計常見問題以及解決方案，業界案例。

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帶來的資料庫訪問壓力

迎工作一到五年的Java工程師朋友們加入Java架構開發：860113481

群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用”沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！

主要在資料架構、效能、儲存成本、服務化等不同方面進行了優化增強