按照業(yè)務(wù)需求, 在業(yè)務(wù)層緩存一定的數(shù)據(jù)以提升性能. 同時(shí)還要保持緩存數(shù)據(jù)和底層數(shù)據(jù)的一致性.
解決的問題
業(yè)務(wù)端通過緩存一定的數(shù)據(jù)避免重復(fù)訪問底層, 從而拉升性能. 然而緩存數(shù)據(jù)和底層數(shù)據(jù)可能存在不一致, 業(yè)務(wù)端必須實(shí)現(xiàn)一定的緩存失效策略來盡可能保證一致性.
方案
很多緩存系統(tǒng)提供read-through, write-through/write-behind這樣的基本操作.
- read-through 就是先讀緩存, 沒找到就去底層拉數(shù)據(jù), 然后更新緩存, 拉升讀效率
- write-through/write-behind 就是先寫緩存, 如果緩存沒命中, 就直接去底層那數(shù)據(jù). 如果緩存命中的話, 那么業(yè)務(wù)線程就更新緩存內(nèi)的數(shù)據(jù), 后臺(tái)線程把一段時(shí)間內(nèi)積累的更新一次性刷回底層. 拉升寫效率
類似這樣的緩存系統(tǒng)對(duì)業(yè)務(wù)端都是透明的, 有特殊需求的話, 業(yè)務(wù)端很可能就要制定自己的失效策略, 以及決策是否使用寫時(shí)緩存.
決策問題
緩存的TTL 需要根據(jù)應(yīng)用需求配置合理的TTL, 如果太短造成緩存連續(xù)失效, 那么這樣的緩存就沒有存在的意義. 如果太長有可能影響客戶的使用體驗(yàn). 緩存數(shù)據(jù)的選取也是一個(gè)問題, 傳統(tǒng)上有LRU Clock-Pro等算法來幫助我們選取需要緩存的數(shù)據(jù). 在實(shí)際應(yīng)用中, 靜態(tài)數(shù)據(jù)是必然可以被緩存在客戶端的, 同時(shí)根據(jù)業(yè)務(wù)形態(tài)我們可以緩存周期性變化的數(shù)據(jù),如一個(gè)每日凌晨更新的統(tǒng)計(jì)數(shù)據(jù)表. 類似的更新策略不能太復(fù)雜.
緩存預(yù)分配 是否在應(yīng)用啟動(dòng)前預(yù)分配, 甚至預(yù)先拉取數(shù)據(jù). 如果這么做可以有效的提升啟動(dòng)時(shí)的性能. 在系統(tǒng)復(fù)雜低時(shí)主動(dòng)拉取數(shù)據(jù), 主動(dòng)開辟大緩存空間等. 實(shí)際實(shí)現(xiàn)可能涉及到復(fù)雜的策略, 所以需要小心權(quán)衡
一致性 由于不保證緩存和底層數(shù)據(jù)一致, 所以部分輸出的結(jié)果可能是陳舊的, 業(yè)務(wù)是否能夠接受這樣的結(jié)果?
本地緩存共享 在多進(jìn)程情況下, 本地的多個(gè)進(jìn)程可能都持有同一個(gè)數(shù)據(jù)的緩存. 但緩存內(nèi)的數(shù)據(jù)卻可能不一致, 這一方面帶來了不一致性, 另外一方面也帶來了空間上的浪費(fèi). 在同一臺(tái)物理機(jī)上的進(jìn)程是否應(yīng)該共享緩存. 整個(gè)系統(tǒng)因此變的復(fù)雜和更難維護(hù)是否可以可以接受的?
