概述

緩存概述

什麼是緩存

緩存在wiki上的定義：用於存儲數據的硬件或軟件的組成部分，以使得後續更快訪問相應的數據。緩存中的數據可能是提前計算好的結果、數據的副本等。典型的應用場景：有cpu cache, 磁盤cache等。本文中提及到緩存主要是指互聯網應用中所使用的緩存組件。

為什麼引入緩存

傳統的後端業務場景中，訪問量以及對響應時間的要求均不高，通常只使用DB即可滿足要求。這種架構簡單，便於快速部署，很多網站發展初期均考慮使用這種架構。但是隨著訪問量的上升，以及對響應時間的要求提升，單DB無法再滿足要求。這時候通常會考慮DB拆分(sharding)、讀寫分離、甚至硬件升級(SSD)等以滿足新的業務需求。但是這種方式仍然會面臨很多問題，主要體現在：

• 性能提升有限，很難達到數量級上的提升，尤其在互聯網業務場景下，隨著網站的發展，訪問量經常會面臨十倍、百倍的上漲。

• 成本高昂，為了承載N倍的訪問量，通常需要N倍的機器，這個代價難以接受。

一丶分佈式高併發緩存設計系統

總體架構圖

1.2自定義的客戶端協議

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

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

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

1.2負載均衡與容錯機制

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

一份緩存數據保留兩份，當前hash節點和下一個真實的hash節點，單個節點down機時，緩存也不會馬上失效

cacheMan是一個弱的管理節點，負責監控，刪除節點，新增節點，可以任意啟停

1.3緩存維護與淘汰機制

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

客戶端LRU緩存

cacheProxy代理LRU緩存

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

1.4安全機制

redis實例都會開啟auth功能

redis實例都監聽在內網ip

1.5核心流程

新增redis節點

刪除redis節點

set緩存

get緩存

二丶問題

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

三丶解決方案

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

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

類型穩定性擴展性通用性對代碼的侵入性

應用層緩存應用會頻繁重啟更新，緩存易丟失，穩定性不佳差，受限於進程的資源限制差，不同應用難以複用代碼侵入性小，無網絡操作，只需要操作應用進程內存

本地單點緩存獨立的緩存應用（redis、memcached等），不會頻繁重啟，穩定性一般，但有單點故障問題一般，受限於單服務器資源限制一般，業務應用和緩存應用有強耦合代碼侵入性一般，需要引入對應的api通常有網絡操作

分佈式內存緩存分佈式系統，具備故障自動恢復功能，無單點故障問題，穩定性佳好，支持水平擴展好，對業務層提供通用接口，後端具體的緩存應用對業務透明代碼侵入性一般，需要引入通用的api通常有網絡操作。

總結

到這裡，深入理解分佈式高併發緩存設計系統就結束了，，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和大家交流幾點編程的經驗：

1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。

3丶 簡化編程，加快速度，代碼風騷，在你完成編碼後，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。

最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。

內部交流群469717771 歡迎各位前來交流和分享， 驗證：（007）

Java小毛驢，頭條出品，每天一篇乾貨，喜歡就收藏＋關注