分佈式內存緩存系統設計

1.問題

任何平臺隨着用戶規模的擴大、功能不斷的添加，持久化數據庫層承受的讀寫壓力會愈來愈大，一旦數據庫承壓過大會致使讀寫性能陡然降低，嚴重時會致使大量的業務請求超時，進而發生「雪崩」引起嚴重的故障。

2.解決方案

在業務層和數據庫持久層之間引入一層內存緩存層，對於複雜且業務邏輯上不會變化的查詢結果進行緩存，業務請求再次發起時，每次都先從緩存層中查詢，從而大大減小對數據庫的查詢，減少對數據庫的壓力。

3.分佈式內存緩存、本地單點緩存、應用層緩存對比

類型	穩定性	擴展性	通用性	對代碼的侵入性
應用層緩存	應用會頻繁重啓更新，緩存易丟失，穩定性不佳	差，受限於進程的資源限制	差，不一樣應用難以複用	代碼侵入性小，無網絡操做，只須要操做應用進程內存
本地單點緩存	獨立的緩存應用（redis、memcached等），不會頻繁重啓，穩定性通常，但有單點故障問題	通常，受限於單服務器資源限制	通常，業務應用和緩存應用有強耦合	代碼侵入性通常，須要引入對應的api一般有網絡操做
分佈式內存緩存	分佈式系統，具有故障恢復功能，無單點故障問題，穩健性佳	好，支持水平擴展	好，對業務層提供通用接口，後端具體的緩存應用對業務透明	代碼侵入性通常，須要引入通用的api一般有網絡操做

4.分佈式內存緩存系統設計

4.1整體架構圖

4.2自定義的客戶端協議

• 業務模塊採用自定義應用層協議和cacheProxy交互

• 整個cache後端採用什麼協議，什麼存儲（redis，memcached等）對業務模塊透明

• cache後端和業務端進行了隔離，修改互不影響

4.3負載均衡與容錯機制

• 採用一致性hash算法，即便部分節點down機，也不會致使所有的緩存失效，新增節點也不會致使大量緩存失效和重建
  

• 一份緩存數據保留兩份，當前hash節點和下一個真實的hash節點（超時時間只有設置的超時時間的一半），單個節點down機時，緩存也不會立刻失效
  

• cacheMan是一個弱的管理節點，負責監控，刪除節點，新增節點，能夠任意啓停

4.4緩存維護與淘汰機制

redis原生超時機制+三層LRU緩存架構，減小最終穿透到redis實例上的請求。

• 客戶端LRU緩存

• cacheProxy代理LRU緩存

• redis實例內存總量限制+LRU緩存

4.5安全機制

• redis實例都會開啓auth功能

• redis實例都監聽在內網ip

4.6核心流程

• 新增redis節點
  

• 刪除redis節點
  

• set緩存
  

• get緩存
  

5.參考資源

• 一致性hash原理：http://blog.codinglabs.org/ar...

• 一致性hash實現：https://github.com/pzx6019171...

• redis通信協議規範：http://www.redis.cn/topics/pr...