1.問題
任何平臺隨著用戶規(guī)模的擴大、功能不斷的添加，持久化數(shù)據(jù)庫層承受的讀寫壓力會越來越大，一旦數(shù)據(jù)庫承壓過大會導致讀寫性能陡然下降，嚴重時會導致大量的業(yè)務請求超時，進而發(fā)生“雪崩”引發(fā)嚴重的故障。
2.解決方案
在業(yè)務層和數(shù)據(jù)庫持久層之間引入一層內存緩存層，對于復雜且業(yè)務邏輯上不會變化的查詢結果進行緩存，業(yè)務請求再次發(fā)起時，每次都先從緩存層中查詢，從而大大減少對數(shù)據(jù)庫的查詢，減小對數(shù)據(jù)庫的壓力。
3.分布式內存緩存、本地單點緩存、應用層緩存對比
| 類型 | 穩(wěn)定性 | 擴展性 | 通用性 | 對代碼的侵入性 |
|---|---|---|---|---|
| 應用層緩存 | 應用會頻繁重啟更新，緩存易丟失，穩(wěn)定性不佳 | 差，受限于進程的資源限制 | 差，不同應用難以復用 | 代碼侵入性小，無網(wǎng)絡操作，只需要操作應用進程內存 |
| 本地單點緩存 | 獨立的緩存應用（redis、memcached等），不會頻繁重啟，穩(wěn)定性一般，但有單點故障問題 | 一般，受限于單服務器資源限制 | 一般，業(yè)務應用和緩存應用有強耦合 | 代碼侵入性一般，需要引入對應的api通常有網(wǎng)絡操作 |
| 分布式內存緩存 | 分布式系統(tǒng)，具備故障自動恢復功能，無單點故障問題，穩(wěn)定性佳 | 好，支持水平擴展 | 好，對業(yè)務層提供通用接口，后端具體的緩存應用對業(yè)務透明 | 代碼侵入性一般，需要引入通用的api通常有網(wǎng)絡操作 |
4.分布式內存緩存系統(tǒng)設計
4.1總體架構圖
總體架構圖.jpg
4.2自定義的客戶端協(xié)議
- 業(yè)務模塊采用自定義應用層協(xié)議和cacheProxy交互
- 整個cache后端采用什么協(xié)議，什么存儲（redis，memcached等）對業(yè)務模塊透明
- cache后端和業(yè)務端進行了隔離，修改互不影響
4.3負載均衡與容錯機制
- 采用一致性hash算法，即使部分節(jié)點down機，也不會導致全部的緩存失效，新增節(jié)點也不會導致大量緩存失效和重建
普通hash.jpg
一致性hash.jpg
- 一份緩存數(shù)據(jù)保留兩份，當前hash節(jié)點和下一個真實的hash節(jié)點，單個節(jié)點down機時，緩存也不會馬上失效
數(shù)據(jù)冗余.jpg
- cacheMan是一個弱的管理節(jié)點，負責監(jiān)控，刪除節(jié)點，新增節(jié)點，可以任意啟停
4.4緩存維護與淘汰機制
redis原生超時機制+三層LRU緩存架構，減少最終穿透到redis實例上的請求。
- 客戶端LRU緩存
- cacheProxy代理LRU緩存
- redis實例內存總量限制+LRU緩存
4.5安全機制
- redis實例都會開啟auth功能
- redis實例都監(jiān)聽在內網(wǎng)ip
4.6核心流程
- 新增redis節(jié)點
新增redis節(jié)點.jpg
- 刪除redis節(jié)點
刪除redis節(jié)點.jpg
- set緩存
set緩存.jpg
- get緩存
get緩存.jpg
5.參考資源
- 一致性hash原理：http://blog.codinglabs.org/articles/consistent-hashing.html
- 一致性hash實現(xiàn)：https://github.com/pzx601917159/consistenthash
- redis通訊協(xié)議規(guī)范：http://www.redis.cn/topics/protocol.html
6.寫在最后
后續(xù)我會在 Linux C/C++后端研發(fā)菜鳥成長記 這個專題中一步一步編碼實現(xiàn)這個設計。
