理解分佈式系統中的緩存架構(下)

做者 陳彩華
文章轉載交流請聯繫 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帶來的數據庫訪問壓力

主要在數據架構、性能、儲存成本、服務化等不一樣方面進行了優化加強

更多精彩，歡迎關注做者公衆號【分佈式系統架構】

參考

從0開始學架構 —— Alibaba 李運華

Java核心技術36講—— Oracle 楊曉峯

微博Cache架構設計實踐 —— 陳波

緩存在大型分佈式系統中的最佳應用 —— 侯忠好

緩存，併發更新的大坑？ —— 58沈劍

分佈式緩存設計—— crossoverJie