五分鐘技術(shù)趣談 | 本地緩存技術(shù)探索

作者：盛磊，單位：中國移動智慧家庭運(yùn)營中心

緩存技術(shù)在高流量、大并發(fā)的應(yīng)用服務(wù)中是一把利器，使用緩存可以降低數(shù)據(jù)庫訪問壓力、提高接口響應(yīng)速度。緩存技術(shù)分為本地緩存和分布式緩存，二者各有利弊。本地緩存無法在集群中進(jìn)行共享，存在應(yīng)用服務(wù)重啟數(shù)據(jù)丟失、需要重新預(yù)熱加載的問題，而分布式緩存如redis、Memcached可以解決此類問題。但是由于本地緩存沒有分布式緩存的網(wǎng)絡(luò)io耗時和集中化依賴問題，依然在很多業(yè)務(wù)場景中有著獨(dú)到的應(yīng)用。本文主要介紹現(xiàn)有的主流本地緩存技術(shù)以及挑戰(zhàn)，并提出一種自研本地緩存技術(shù)。

Part 01●??本地緩存使用場景?●

在程序中，有些表數(shù)據(jù)，數(shù)據(jù)量有限，但是程序啟動就會馬上訪問，并且訪問的很頻繁，比如（例如配置參數(shù)，區(qū)域信息）。針對這種情況，可以將數(shù)據(jù)放到程序的本地緩存中即內(nèi)存中，從而提高系統(tǒng)的訪問效率、減少數(shù)據(jù)庫訪問。此外，相比本地緩存，數(shù)據(jù)庫訪問、分布式緩存會占用連接，存在網(wǎng)絡(luò)消耗，本地緩存只需要考慮緩存占用的內(nèi)存空間、緩存的失效策略。數(shù)據(jù)庫、本地緩存及分布式緩存的區(qū)別如下表所示：

Part 02●??現(xiàn)狀和挑戰(zhàn)?●

2.1 Map

Map是一種k-v數(shù)據(jù)結(jié)構(gòu)，非常方便于自己實(shí)現(xiàn)本地緩存，比如使用HashMap全局變量，主要需要考慮啟動或調(diào)用時加載數(shù)據(jù)、線程安全、內(nèi)存泄漏、內(nèi)存溢出等問題。常用的ConcurrentHashMap通過Node數(shù)組、鏈表、紅黑樹等數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)數(shù)據(jù)分段和鎖保護(hù)，兼顧了訪問性能和安全性。

此外，自己實(shí)現(xiàn)本地緩存好處在于，可以靈活控制緩存寫入時機(jī)，可以結(jié)合業(yè)務(wù)應(yīng)用的啟動時機(jī)、通知機(jī)制或調(diào)用，自己控制未命中時查詢并寫入還是服務(wù)啟動時就全量預(yù)熱。

但是，通過Map自研實(shí)現(xiàn)本地緩存，需要顯式刪除才能將數(shù)據(jù)從緩存中清理；如果不考慮內(nèi)存大小限制，一旦候選緩存數(shù)據(jù)量很大，容易出現(xiàn)內(nèi)存溢出問題，造成服務(wù)崩潰造成重大線上問題，而自研實(shí)現(xiàn)緩存限制策略又增加了復(fù)雜性和維護(hù)風(fēng)險。因此，要不要自研實(shí)現(xiàn)本地緩存，需要綜合考慮待緩存數(shù)據(jù)量與技術(shù)難度風(fēng)險。

2.2 Guava Cache

Guava Cache是google實(shí)現(xiàn)的開源本地緩存技術(shù)，開箱即用，解決了實(shí)際應(yīng)用中遇到的大多問題，是常用的本地緩存技術(shù)。構(gòu)建一個本地緩存實(shí)例示例代碼如下：

Guava cache類似于concurrentHashMap，但是與之不同的是，concurrentHashMap需要顯式地刪除緩存，同時難以控制對本地內(nèi)存的使用量。在緩存失效策略和本地內(nèi)存占用控制方面，GuavaCache都有靈活的可選擇控制策略。

2.3 緩存失效策略

2.3.1基于大小的失效策略

2.3.2基于時間的失效策略

2.3.3基于引用的失效

此外，GuavaCache支持本地緩存對象刪除的監(jiān)聽機(jī)制，在實(shí)際應(yīng)用中，可以通過分析key刪除的原因，綜合評價本地緩存大小和失效策略設(shè)計(jì)的合理性，方便進(jìn)一步優(yōu)化本地緩存設(shè)置。

2.4 Caffeine

Caffeine cache與Guava cache非常類似，比如上面講到的guava cache三大類過期策略，caffeine都有。但是由于Guava cache基于LRU淘汰算法，而Caffeine 因?yàn)槭褂昧?Window-TinyLFU 緩存淘汰策略，提供了一個近乎最佳的命中率，綜合了 LRU 和 LFU 算法的長處，使其成為本地緩存之王。

Window-TinyLFU算法原理如上圖所示，基本原理是將Cache分成了幾個區(qū)，新數(shù)據(jù)放到Window Cache，滿了之后使用LRU進(jìn)行晉升Probation Cache，然后再根據(jù)TinyLYU算法決定是否再次晉級，或者淘汰，詳細(xì)的晉升和淘汰機(jī)制可以百度學(xué)習(xí)?？吹竭@里，是不是覺得這套算法邏輯頗像JVM的分代回收算法，果然分區(qū)而治才是王道。

Caffeine封神除了淘汰算法無敵之外，還提供了AsyncLoadingCache，可以自定義線程池，多線程異步的好處在于調(diào)用方可以針對某些獲取源數(shù)據(jù)耗時選擇阻塞等待或非阻塞，防止因?yàn)槟承┥倭砍瑫r導(dǎo)致load阻塞問題。

Caffeine還內(nèi)置了統(tǒng)計(jì)功能，通過Caffeine.recordStats()打開數(shù)據(jù)收集，然后Cache.stats()方法將會返回當(dāng)前緩存的一些統(tǒng)計(jì)指標(biāo)，例如：

hitRate()：查詢緩存的命中率

evictionCount()：被驅(qū)逐的緩存數(shù)量

averageLoadPenalty()：新值被載入的平均耗時

不過開啟統(tǒng)計(jì)功能會有一些性能損耗，這個需要具體評估。

Part 03●??自研本地緩存技術(shù)?●

上述介紹的中間件技術(shù)，基本可以滿足絕大多數(shù)開發(fā)場景，但是在實(shí)際應(yīng)用中，經(jīng)常遇到需要全量緩存表數(shù)據(jù)的場景，比如規(guī)則引擎中配置的通用規(guī)則，告警過濾規(guī)則等，這種基于全量預(yù)熱數(shù)據(jù)的本地緩存需求，主要要求緩存更新的實(shí)時性與數(shù)據(jù)完整性，與上述基于key-value命中的緩存機(jī)制不太相符，因此這里介紹一種自研的緩存全量數(shù)據(jù)的本地緩存技術(shù)。

該技術(shù)是要緩存表中全量有效數(shù)據(jù)，基于三個關(guān)鍵的表設(shè)計(jì)字段：update_time（更新時間）、status（數(shù)據(jù)狀態(tài)）、unique_key（表征數(shù)據(jù)唯一或通過計(jì)算保證唯一的字段），通過內(nèi)置的單線程定時任務(wù)，實(shí)現(xiàn)本地緩存的增量更新和全量更新，同時兼顧了緩存更新的時效性和準(zhǔn)確性，由于不需要依賴其他中間件，可以有效應(yīng)用在所有的業(yè)務(wù)系統(tǒng)中?；驹砣缦聢D所示：

1.服務(wù)啟動時執(zhí)行一次全量數(shù)據(jù)加載，開啟定時任務(wù)，并記錄當(dāng)前時間t0為全量更新時間t1和增量更新時間t2。

2.每次定時任務(wù)執(zhí)行時，如果(當(dāng)前時間t-上次全量更新時間t1)>全量更新時間閾值max1，則執(zhí)行一次全量數(shù)據(jù)對齊，并刷新全量更新時間t1=t。當(dāng)然這個策略看實(shí)際需求是否有必要。

3.如果未觸發(fā)全量更新，會增量查詢 (當(dāng)前時間t-上次增量更新時間t2)時間區(qū)間內(nèi)表中更新數(shù)據(jù)，并更新t2=t。

4.如果第3步查詢到有更新數(shù)據(jù)，則增量更新到本地緩存（要求表設(shè)計(jì)為邏輯刪除）。

5.定時任務(wù)不斷重復(fù)2~4步驟即可。

Part 04●??總結(jié)?●

本地緩存是服務(wù)開發(fā)者做性能優(yōu)化的重要技術(shù)手段之一，本篇介紹了常用的幾種本地緩存技術(shù)方案。本著拿來主義的原則，通過需求場景評估后，如果這些成熟的本地緩存中間件能夠滿足需求，則優(yōu)先選用，如guava cache, caffeine。自己實(shí)現(xiàn)的好處在于能夠靈活控制本地緩存讀、寫、失效、監(jiān)聽等各種時機(jī)，可以更加深入融合實(shí)際需求，但也存在內(nèi)存控制、內(nèi)存泄漏、并發(fā)問題等挑戰(zhàn)，所以需要綜合評判。