最近在思考一個問題：緩存。
很可惜最后沒有能實(shí)現(xiàn)自己的想法，就在這里做個記錄好了。
出于限制條件，我沒辦法使用redis這類緩存數(shù)據(jù)庫，所以在思考node輕量級緩存的操作，簡單來說就是數(shù)據(jù)存儲在一個變量，放在內(nèi)存里。
情況
我有一個完整的網(wǎng)站，前后端和數(shù)據(jù)庫都是完備的。
需求方提供了兩個數(shù)據(jù)源，需要我們提供一個頁面查詢這兩個數(shù)據(jù)源的數(shù)據(jù)顯示，并提供添加數(shù)據(jù)到我們數(shù)據(jù)庫的操作。查詢是由多個key來篩選數(shù)據(jù)。
他們提供的數(shù)據(jù)相對穩(wěn)定，為了提高查詢效率，避免網(wǎng)絡(luò)因素造成的延遲我打算做一個緩存，主要是這個以前沒做過比較好玩。
基礎(chǔ)了解
在深入理解緩存這篇文章里面我了解了緩存的基本知識，不過后面java部分的我就沒有看了，寫的挺不錯的。
我主要了解了里面的基礎(chǔ)概念：
緩存主要是利用空間換時間的算法，最關(guān)鍵的是內(nèi)部的淘汰算法。
- 命中率
- 最大元素
- 淘汰算法
FIFO，LRU，LFU，隨機(jī)清除 - 緩存穿透
- 緩存雪崩
- 臟數(shù)據(jù)
數(shù)據(jù)格式統(tǒng)一
我遇到的第一個問題就是數(shù)據(jù)結(jié)構(gòu)不一致。這個當(dāng)時我是有兩種考慮，一種是不管他，直到你存儲的時候再轉(zhuǎn)換就可以了。另一種是從一開始就將數(shù)據(jù)結(jié)構(gòu)統(tǒng)一。兩種方式說不上來那種比較好，比較一下：
- 第一種
無效率問題，但是可能導(dǎo)致后續(xù)處理流程麻煩 - 第二種
有處理效率問題，但是后續(xù)不用再考慮數(shù)據(jù)結(jié)構(gòu)的問題了
我為了避免麻煩，采用了第二種策略，用了async控制流程。
當(dāng)然不管是第一種還是第二種，你都需要一個數(shù)據(jù)結(jié)構(gòu)統(tǒng)一函數(shù)。
緩存淘汰算法
關(guān)于算法的選擇，我看了傳送門前兩篇的文章，特別是看到node-cache 700多顆星和他的源碼感慨，好眼紅！！！
node-chche主要是采用了超時淘汰，就是給每個數(shù)據(jù)設(shè)置一個超時時間，超過時間自己殺死自己。：）每次put會刷新超時時間。基本的數(shù)據(jù)段為value+timeout。
在Node.js中搭建緩存管理模塊主要介紹從數(shù)據(jù)結(jié)構(gòu)設(shè)計到淘汰算法的這個那個過程。淘汰算法采用了LRU和LFO兩種。時間或計數(shù)作為一個維度來決定數(shù)據(jù)的淘汰與否。同時設(shè)置了最大資源占用，還有最后的智能選擇也是很有意思的。
當(dāng)時我選擇我的淘汰算法的時候完全不知道應(yīng)該用哪種，我總想采用第二種里面的一種思路，不過我總想利用時間和計數(shù)形成一個二維選擇數(shù)據(jù)，就是由時間和計數(shù)共同決定數(shù)據(jù)的淘汰。簡單的想法就是時間作為第一維度，計數(shù)作為第二維度。每次命中單個數(shù)據(jù)刷新超時時間，如果計數(shù)達(dá)到一定的頻率，就延長超時時間，利用計數(shù)形成二級緩存，以此來達(dá)到更高的命中率。或者是計數(shù)作為第一維度，時間作為第二維度。這是我的一點(diǎn)思考。
數(shù)據(jù)一致性
這里是我還沒有思考的部分，如果我緩存了一個數(shù)據(jù)，數(shù)據(jù)源方面改了，怎么能保證他的數(shù)據(jù)一致性？這里我是利用crypto進(jìn)行hash存儲，比對來保證數(shù)據(jù)的一致，但是這種修改會導(dǎo)致的臟數(shù)據(jù)就沒辦法處理了。最后的殺手锏是提供給用戶一個清空緩存的按鈕。：）
總結(jié)
其實(shí)除了我提到的這些，還有很多其他的問題，兩個數(shù)據(jù)源怎么統(tǒng)一，整個流程模塊的拆分，緩存數(shù)據(jù)怎么存儲，多個key怎么利用才能盡可能避免緩存穿透等等，雖然沒做出來這個但是收獲還是很多。
傳送門
在Node.js中搭建緩存管理模塊
node-cache 模塊 node.js 輕量級緩存管理使用及源碼分析
memory-cache
深入理解緩存
