今天組里的同學(xué)和我談起local cache的一點需求，希望考慮在性能和業(yè)務(wù)上找到平衡點應(yīng)該怎么考慮實現(xiàn)。下午給他的意見可能還是有點問題，回家稍微整理了一下，說出來也可以激發(fā)大家的討論，覺得現(xiàn)在local cache + 遠端cache是提高性能的必備，所以如何做好local cache 很有講究。
由于有網(wǎng)絡(luò)傳輸帶來的性能損失（包括連接數(shù)并發(fā)限制），很多大請求量系統(tǒng)都會考慮做部分本地緩存。但本地緩存最大的問題就是數(shù)據(jù)同步，如果讓集中式存儲（cache,queue）來通知只會增加復(fù)雜度，因此通常最簡單的方式就是根據(jù)業(yè)務(wù)數(shù)據(jù)的敏感度設(shè)置不同長短的本地失效時間。但現(xiàn)在如果要設(shè)置一個較短的有效期（例如一秒），對于計算機來說已經(jīng)大大的減輕了壓力（1秒對程序來說太久了），但是整體本地緩存對后端保護的效果不佳（特別是后端如果是并發(fā)處理能力較弱的系統(tǒng)），如果遇到并發(fā)量大的系統(tǒng)，那么就更為突出了。
早先有想過通過鎖來保證請求不會全部放過去（失效時就一個請求過去更新，其他請求等待），一來是針對內(nèi)容作鎖，對鎖的需求量很大（當(dāng)業(yè)務(wù)數(shù)據(jù)很多時），二來如果采用其他請求阻塞（對于系統(tǒng)來說壓力也很大），這點后來談起可以直接返回老數(shù)據(jù)而不等待。但總體看起來消耗依然很大。
因此給了下圖：
首先開始的時候會有部分?jǐn)?shù)據(jù)被推送到本地緩存（當(dāng)然也可以是客戶端主動獲取全部數(shù)據(jù)），也可以全部采用lazy加載，推送來的數(shù)據(jù)緩存在本地，并且設(shè)置失效時間，為每一個key還會有一份失效時間Map用于檢查是否失效。應(yīng)用發(fā)起get的請求，先從本地拿，如果有數(shù)據(jù)且有效，就直接返回。如果沒有命中，則去遠端獲取資源，并緩存在本地，最后返回給應(yīng)用（這里如果要防攻擊可以采用布隆算法建立白名單）。如果發(fā)現(xiàn)本地數(shù)據(jù)失效，則將失效事件放入到一個本地的EventMap中，key為當(dāng)前請求數(shù)據(jù)的key，然后設(shè)置這個key的時間為當(dāng)前時間+有效間隔時間（不做并發(fā)控制，多次放入EventMap會被覆蓋，多次設(shè)置時間有效期還是當(dāng)前時間+間隔時間），后續(xù)請求就會認為這個數(shù)據(jù)是有效的不會連續(xù)請求更新，然后返回老數(shù)據(jù)。后臺分發(fā)線程檢查消息Map，將事件分發(fā)到后臺線程池異步執(zhí)行，最后更新結(jié)果并設(shè)置有效時間。
最后還有一個后臺清理線程將過老的數(shù)據(jù)從緩存中移除，在map滿或者到了清理間隔的時候去執(zhí)行。
這種設(shè)計有一定的復(fù)雜度，但是還算是松耦合，在并發(fā)高的情況下，犧牲數(shù)據(jù)較小的即時性換取對后端的保護。不過如果沒有必要，做的簡單粗暴一點即可，不需要那么復(fù)雜。同時如果有更好的意見和建議的同學(xué)請回帖討論，或者去我的微薄討論: t.sina.com.cn/fangweng