今天接到一個需求，在聊天界面右下角新增一個運營活動位，活動信息會通過一個HTTPS接口返回，同時每個活動有一個過期倒計時，在這個倒計時結(jié)束之前，后臺希望前端不要再次請求了。具體的流程如下
上面例子的特點是后臺明確知道數(shù)據(jù)失效的時間
兩個星期前，產(chǎn)品提了一個需求，增加一個動態(tài)表情搜索模式，進入該模式的時候自動自動展示全平臺最火的20個動態(tài)表情，經(jīng)過和后端同學(xué)溝通發(fā)現(xiàn)，雖然表情是從實時隊列中取的前20個，但是基本前二十在當(dāng)天的變化不大，因此不希望客戶但每次進入搜索模式的時候都調(diào)用一次，最終協(xié)商之后客戶端每次進入聊天界面的時候調(diào)用一次。
上面例子的特點是后臺不知道數(shù)據(jù)什么時候失效，但是確定短時間內(nèi)不會失效
類似的需求和實現(xiàn)在客戶端中挺多的，最終積累下來，每次客戶端啟動的時候請求的接口多達10個，為了避免這種短時間不會失效的數(shù)據(jù)頻繁請求，我們用了幾個配置接口做數(shù)據(jù)下發(fā)。
為此我們需要一種緩存機制
說到緩存，繞不開幾個特性
- 命中率
- 查詢速度
- 時效性，避免使用過期的緩存
- 占用空間，過小命中率低，過大則占用空間
- 為了保證命中率，起碼根據(jù)28法則，我們最好最少要有足夠的空間保存常用的那20%的數(shù)據(jù)
- 當(dāng)本地的數(shù)據(jù)足夠多之后，我們也要確保高效的查詢效率
- 當(dāng)使用緩存的手段之后，我們也要確保數(shù)據(jù)的新鮮度，過期的數(shù)據(jù)一律需要摒棄，重新向服務(wù)器發(fā)起請求
- 緩存不是保存越多越好，首先緩存消耗內(nèi)存，也消耗用戶本地空間，因此需要設(shè)置最大的緩存大小，同時需要兼顧命中率
設(shè)計一個緩存功能
- 依賴后臺數(shù)據(jù)的客戶端其實不需要怎么考慮命中率，除非最大緩存空間設(shè)置過小，導(dǎo)致用到的緩存被頻繁刪除
- 查詢速度，為了占用空間和查詢速度，我們用請求URL進行MD5，作為文件名，同時進行Hash記錄
- 時效性，如果后臺明確告訴我們失效時間了，那么就在失效時間過期之后再去請求數(shù)據(jù)，否則我們需要跟后臺約定，對數(shù)據(jù)進行hash，請求的時候帶上本地記錄的hash碼，后臺通過對比hash碼，決定是否要給客戶端返回數(shù)據(jù)
- 客戶端應(yīng)該設(shè)置緩存最大數(shù)，并且通過使用合適的淘汰算法，移除超過大小的數(shù)據(jù)，這里我們用LRU，不用FIFO
通過請求數(shù)據(jù)，Hash、LRU、DiskLRU一頓操作之后，我們就可以有效得減少用戶流量消耗，加快應(yīng)用的啟動速度，減少服務(wù)器的帶寬壓力、減少流量開銷、降低服務(wù)器數(shù)據(jù)庫壓力
小結(jié)
經(jīng)過上面一頓酣暢淋漓地操作之后，我們?nèi)〉昧瞬诲e的效果，就是客戶端麻煩一點，需要寫一套緩存框架，當(dāng)然我們可以用現(xiàn)成的數(shù)據(jù)結(jié)構(gòu)和淘汰算法，對了，同時iOS的同學(xué)也參考一下，翻譯過去就好了，完美。
即使有這么大的好處，但是最終我還是沒有去實現(xiàn)上面的設(shè)計，不過既然既然今天這個運營活動的流程圖寫好了，服務(wù)端的同學(xué)也給出了接口，那么就這樣做吧。
其實我之所以不想做，是因為只要一行代碼就可以實現(xiàn)上面所有邏輯，但是需要服務(wù)端同學(xué)配合。
