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

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

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架構開發：744677563

本羣提供免費的學習指導 架構資料 以及免費的解答

不懂得問題均可以在本羣提出來 以後還會有職業生涯規劃以及面試指導

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