誤用一:把緩存作爲服務與服務之間傳遞數據的媒介
如上圖:
- 服務1和服務2約定好key和value,通過緩存傳遞數據
- 服務1將數據寫入緩存,服務2從緩存讀取數據,達到兩個服務通信的目的
該方案存在的問題是:
- 數據管道,數據通知場景,MQ更加適合
- 多個服務關聯同一個緩存實例,會導致服務耦合
誤用二:使用緩存未考慮雪崩
常規的緩存玩法,如上圖:
服務先讀緩存,緩存命中則返回
緩存不命中,再讀數據庫
什麼時候會產生雪崩?
答:如果緩存掛掉,所有的請求會壓到數據庫,如果未提前做容量預估,可能會把數據庫壓垮(在緩存恢復之前,數據庫可能一直都起不來),導致系統整體不可服務。
如何應對潛在的雪崩?
答:提前做容量預估,如果緩存掛掉,數據庫仍能扛住,才能執行上述方案。
否則,就要進一步設計。
常見方案一:高可用緩存
如上圖:使用高可用緩存集羣,一個緩存實例掛掉後,能夠自動做故障轉移。
常見方案二:緩存水平切分
如上圖:使用緩存水平切分,一個緩存實例掛掉後,不至於所有的流量都壓到數據庫上。
誤用三:調用方緩存數據
如上圖:
- 服務提供方緩存,向調用方屏蔽數據獲取的複雜性(這個沒問題) 服務
- 調用方,也緩存一份數據,先讀自己的緩存,再決定是否調用服務(這個有問題)
該方案存在的問題是:
- 調用方需要關注數據獲取的複雜性
- 更嚴重的,服務修改db裏的數據,淘汰了服務cache之後,難以通知調用方淘汰其cache裏的數據,從而導致數據不一致
- 有人說,服務可以通過MQ通知調用方淘汰數據,額,難道下游的服務要依賴上游的調用方,分層架構設計不是這麼玩的
誤用四:多服務共用緩存實例
如上圖:
- 服務A和服務B共用一個緩存實例(不是通過這個緩存實例交互數據)
該方案存在的問題是:
- 可能導致key衝突,彼此沖掉對方的數據
畫外音:可能需要服務A和服務B提前約定好了key,以確保不衝突,常見的約定方式是使用namespace:key的方式來做key。 - 不同服務對應的數據量,吞吐量不一樣,共用一個實例容易導致一個服務把另一個服務的熱數據擠出去
- 共用一個實例,會導致服務之間的耦合,與微服務架構的“數據庫,緩存私有”的設計原則是相悖的
建議的玩法是:
如上圖:各個服務私有化自己的數據存儲,對上游屏蔽底層的複雜性。
總結
緩存使用小技巧:
- 服務與服務之間不要通過緩存傳遞數據
- 如果緩存掛掉,可能導致雪崩,此時要做高可用緩存,或者水平切分
- 調用方不宜再單獨使用緩存存儲服務底層的數據,容易出現數據不一致,以及反向依賴
- 不同服務,緩存實例要做垂直拆分