設計緩存系統該注意的問題

分佈式緩存對應於CPU的模型有以下的關係,咱們知道,CPU跟內存的關係中間還有三級高速緩存L1,L2,L3.L1最靠近CPU內核,CPU在進行數據處理的時候通常是先把內存的數據複製到L1中進行處理,把處理結果恢復到內存中,因此多CPU多線程中會有數據複製不一致的問題.

而對應於分佈式緩存系統中,有着與之對應的關係(寄存器-本地內存,L1緩存-本地內存,L2緩存-本地內存,L3緩存-Redis分佈式緩存,內存-數據庫Mysql等).

創建分佈式緩存的3種方法:一、雙讀雙寫，通常寫數據庫，讀緩存，緩存未命中，則讀取數據庫，再寫入緩存。二、異步更新，只讀寫緩存，由異步的更新服務將數據庫裏的變動或者新增的數據更新到緩存中。三、串聯模式，直接在緩存上進行讀寫操做，緩存做爲代理，根據須要和配置與數據庫進行讀寫操做。

緩存穿透：

緩存穿透是指使用不存在的key進行大量的高併發查詢,致使緩存沒法命中,直接穿透到後端的數據庫系統進行查詢,使數據庫壓力過大,甚至壓死數據庫.解決辦法:存儲空值,過濾規則,不符合規則的訪問,直接拒絕.

緩存併發：

緩存併發,當一個key過時時,訪問這個key的請求量過大,穿透到數據庫.解決辦法:1,分佈式鎖,保證每一個key同時只有一個線程去查詢數據庫,其餘線程沒有得到分佈式鎖的權限,只須要等待.對分佈式鎖的考驗很大.2,本地鎖,類比分佈式鎖,但可能會有不一樣節點的線程查詢數據庫.3,軟過時,業務層處理.

緩存雪崩：

緩存雪崩,緩存服務器重啓或者大量緩存集中在某一個時間段內失效,給數據庫形成瞬時壓力.解決辦法,對不一樣的數據使用不一樣的失效時間,對相同的數據,不一樣的請求使用不一樣的失效時間,過時時間採用固定時間+隨機時間,有一個範圍,就能夠避免緩存雪崩.

緩存一致性：

當數據時效性要求很高時，須要保證緩存中的數據與數據庫中的保持一致，並且須要保證緩存節點和副本中的數據也保持一致，不能出現差別現象。這就比較依賴緩存的過時和更新策略。通常會在數據發生更改的時，主動更新緩存中的數據或者移除對應的緩存。

緩存顛簸問題：

緩存的顛簸問題，有些地方可能被成爲「緩存抖動」，能夠看作是一種比「雪崩」更輕微的故障，可是也會在一段時間內對系統形成衝擊和性能影響。通常是因爲緩存節點故障致使。業內推薦的作法是經過一致性Hash算法來解決。

緩存無底洞問題：

該問題由 facebook 的工做人員提出的， facebook 在 2010 年左右，memcached 節點就已經達3000 個，緩存數千 G 內容。他們發現了一個問題---memcached 鏈接頻率，效率降低了，因而加 memcached 節點，添加了後，發現由於鏈接頻率致使的問題，仍然存在，並無好轉，稱之爲」無底洞現象」。