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