?2016-2026 Matools All rights reserved,
粵ICP備17059708號
導(dǎo)讀
按照現(xiàn)在流行的互聯(lián)網(wǎng)分層架構(gòu)模型，最簡單的架構(gòu)當(dāng)屬Web響應(yīng)層+DB存儲層的架構(gòu)。從最開始的單機混合部署Web和DB，到后來將二者拆分到不同物理機以避免共享機器硬件帶來的性能瓶頸，再隨著流量的增長，Web應(yīng)用變?yōu)榧翰渴鹉Ｊ?，而DB則衍生出主從機來保證高可用，同時便于實現(xiàn)讀寫分離。這一連串系統(tǒng)架構(gòu)的升級，本質(zhì)上是為了追求更高的性能，達到更低的延時。
高德作為一款國民級別的導(dǎo)航軟件，導(dǎo)航路線的數(shù)據(jù)質(zhì)量是由數(shù)據(jù)中心統(tǒng)一管理的。為了保證數(shù)據(jù)的鮮度，數(shù)據(jù)中心需要對不斷變化的現(xiàn)實道路數(shù)據(jù)進行收集，將這些變化的信息保存到數(shù)據(jù)庫中，從而保證導(dǎo)航數(shù)據(jù)的鮮度；另一方面數(shù)據(jù)中心內(nèi)部多部門協(xié)調(diào)生產(chǎn)數(shù)據(jù)的時候，會產(chǎn)生海量請求查詢最新生產(chǎn)的數(shù)據(jù)，這就要求數(shù)據(jù)的管理者要控制數(shù)據(jù)庫連接數(shù)，降低請求的響應(yīng)耗時，同時也需要保證返回數(shù)據(jù)的實時性。
在平衡數(shù)據(jù)鮮度和性能之間，高德數(shù)據(jù)中心針對不同的業(yè)務(wù)場景使用了不同的策略，達到了數(shù)據(jù)變更和緩存同步低延遲的目標(biāo)，同時保障了系統(tǒng)的穩(wěn)定性。
本文將提及的緩存技術(shù)則是提升性能的另一把利刃。然而任何技術(shù)都是有可為有可不為，沒有最好的技術(shù)只有最適合的技術(shù)，因此在使用緩存之前，我們也需要了解下引入緩存模塊所帶來的好處和壞處。
緣起：為何使用緩存
在應(yīng)用對外提供服務(wù)時，其穩(wěn)定性受到諸多因素影響，其中比較重要的有CPU、內(nèi)存、IO(磁盤IO、網(wǎng)絡(luò)IO)等，這些硬件資源十分寶貴，因此對于那些需要經(jīng)過復(fù)雜計算才能得到結(jié)果的，或者需要頻繁讀取磁盤數(shù)據(jù)的，最好將結(jié)果緩存起來，避免資源的重復(fù)消耗。
CPU瓶頸
如果項目中有很多正則表達式計算，或者某個計算結(jié)果是多次中間結(jié)果合并后才得出的，且CPU的使用率一直居高不下，那么就可以考慮是否應(yīng)該將這些結(jié)果緩存起來，根據(jù)特定Key直接獲取Value結(jié)果，減少中間鏈路的傳遞過程，減少CPU的使用率。
IO瓶頸
眾所周知，從磁盤獲取數(shù)據(jù)受到磁盤轉(zhuǎn)速、尋道速度、磁盤緩沖區(qū)大小等諸多因素影響，這些因素決定了磁盤的IOPS，同時我們也知道對于數(shù)據(jù)的讀寫來說，CPU的緩存讀寫速度>
內(nèi)存的讀寫速度>磁盤的讀寫速度。雖然磁盤內(nèi)部也配備了緩存以匹配內(nèi)存的讀寫速度，但其容量畢竟是有限的，那么當(dāng)磁盤的IOPS無法進一步提升的時候，便會想到將數(shù)據(jù)緩存到內(nèi)存中，從而降低磁盤的訪問壓力。這一策略常被應(yīng)用于緩解DB數(shù)據(jù)庫的數(shù)據(jù)訪問壓力。
選擇本地緩存和分布式緩存的考量點
既然可以使用緩存來提升系統(tǒng)吞吐能力，那么緊接著遇到的問題就是選擇本地緩存，還是分布式緩存？什么時候需要使用多級緩存呢？接下來，讓我們聊一聊在使用緩存優(yōu)化項目的過程中，本地緩存和分布式緩存的應(yīng)用場景和優(yōu)缺點。
本地緩存的優(yōu)缺點和應(yīng)用場景
統(tǒng)一進程帶來了以下優(yōu)勢：
* 由于本地緩存和應(yīng)用在同一個進程中，因而其穩(wěn)定性很高，達到了和應(yīng)用同生共死的境界；
* 由于在同一進程中，避免了網(wǎng)絡(luò)數(shù)據(jù)傳輸帶來的消耗，所有緩存數(shù)據(jù)直接從進程所在的內(nèi)存區(qū)域獲取即可。
強耦合性也會導(dǎo)致以下這些劣勢：
* 本地緩存和應(yīng)用共享一片JVM內(nèi)存，爭搶內(nèi)存資源，無法水平擴展，且可能造成頻繁的GC，影響線上應(yīng)用的穩(wěn)定性。
* 由于沒有持久化機制，在項目重啟后緩存內(nèi)數(shù)據(jù)就會丟失，對于高頻訪問數(shù)據(jù)，需要對數(shù)據(jù)進行預(yù)熱操作。
* 多份進程內(nèi)緩存存儲著同樣的數(shù)據(jù)內(nèi)容，造成內(nèi)存使用浪費。
* 同樣的數(shù)據(jù)存儲在不同的本地機器，數(shù)據(jù)變化后，很難保證數(shù)據(jù)的一致性。
結(jié)合以上優(yōu)缺點，我們就會想到，如果有一種數(shù)據(jù)需要頻繁訪問，但一旦創(chuàng)建后就輕易不會改變，而且初始創(chuàng)建時就能預(yù)估占用的內(nèi)存空間，那么這種類型的數(shù)據(jù)無疑是最適合用本地緩存存儲了。
既然有了上述的應(yīng)用場景，我們反觀技術(shù)開發(fā)中的訴求，發(fā)現(xiàn)其實很多優(yōu)秀的框架已經(jīng)在這樣使用了，比如緩存類class的反射信息，包括field、method等。因為class的數(shù)量是有限的，且內(nèi)容不會輕易改變，在使用時無需再使用反射機制，而只需要從本地緩存讀取數(shù)據(jù)即可。
分布式緩存的優(yōu)缺點和應(yīng)用場景
優(yōu)勢：
* 數(shù)據(jù)集中存儲，消除冗余數(shù)據(jù)，解決整體內(nèi)存的占用率，易于維護集群建緩存數(shù)據(jù)的一致性。
* 緩存中間件可以對緩存進行統(tǒng)一管理，便于水平擴容。
劣勢：
* 依賴分布式緩存中間件穩(wěn)定性，一旦掛了，容易造成緩存雪崩；
* 由于是跨機器獲取緩存數(shù)據(jù)，因此會造成數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)消耗，以及一些序列化/反序列化的時間開銷。
對于上述缺點中，網(wǎng)絡(luò)耗時等開銷是難免的，而且這些操作耗費的時間在可接受范圍內(nèi)，而對于中間件的穩(wěn)定性則可以通過服務(wù)降級、限流或者多級緩存思路來保證。我們主要看中的是它的優(yōu)點，既然分布式緩存天然能保證緩存一致性，那么我們傾向于將需要頻繁訪問卻又經(jīng)常變化的數(shù)據(jù)存放于此。
選擇緩存框架的衡量標(biāo)準
在了解了何時使用緩存以及緩存的優(yōu)缺點后，我們就準備大刀闊斧開始升級系統(tǒng)了，可緊接著的問題也隨之出現(xiàn)，對于本地緩存和分布式緩存，到底應(yīng)該使用什么框架才是最適用的呢？
現(xiàn)在的技術(shù)百花齊放，不同的技術(shù)解決的問題側(cè)重點也不同，對于本地緩存來說，如果無資源競爭的代碼邏輯，可以使用HashMap，而對于有資源競爭的多線程程序來說，則可以使用ConcurrentHashMap。但以上二者有個通病就是緩存占用只增不減，沒有緩存過期機制、也沒有緩存淘汰機制。
那么本地緩存是否有更高性能的框架呢？而對于分布式緩存，領(lǐng)域內(nèi)常用的Redis和Memcache又應(yīng)該怎樣取舍呢？本小節(jié)期望通過橫向?qū)Ρ鹊姆绞剑謩e給出一個比較通用的緩存框架方案，當(dāng)然如果有個性化需求的，也可以根據(jù)不同緩存框架的特性來取舍。
不同本地緩存框架的橫向?qū)Ρ?，如下表所示?br>
?
?
?
總結(jié)：如果不需要淘汰算法則選擇ConcurrentHashMap，如果需要淘汰算法和一些豐富的API，推薦選擇Caffeine。
不同分布式緩存框架的橫向?qū)Ρ?，如下表所示?br>
?
?
?
對于存儲容量而言，Memcache采用預(yù)先分配不同固定大小存儲單元的方式，內(nèi)存空間使用并不緊湊。如果存儲Value對象大小最大為1MB，那么當(dāng)一個對象有1000KB，那么會存儲到大小最匹配1MB的單元中，因此會浪費24KB的內(nèi)存；而Redis是使用之前才去申請空間，內(nèi)存使用緊湊，但頻繁對內(nèi)存的擴容和收縮，可能造成內(nèi)存碎片。
總結(jié)：由于Redis具有豐富的數(shù)據(jù)結(jié)構(gòu)能滿足不同的業(yè)務(wù)場景需求，同時Redis支持持久化，能有效地解決緩存中間件重啟后的數(shù)據(jù)預(yù)加載問題，因此大多數(shù)應(yīng)用場景中還是推薦使用Redis。
緩存框架使用過程的知識點
不論是本地緩存還是分布式緩存，在使用緩存提升性能的時候，必然會考慮緩存命中率的高低，考慮緩存數(shù)據(jù)的更新和刪除策略，考慮數(shù)據(jù)一致性如何維護，本小節(jié)主要針對以上的問題來分析不同實現(xiàn)方案的優(yōu)缺點。
緩存命中率
緩存命中率不僅是系統(tǒng)性能的一個側(cè)面指標(biāo)，也是優(yōu)化緩存使用方案的一個重要依據(jù)。緩存命中率=請求命中數(shù)/請求總數(shù)。接下來的若干緩存使用策略所圍繞的核心考量點就是在保證系統(tǒng)穩(wěn)定性的同時，旨在提升緩存命中率。
緩存更新策略
主動請求DB數(shù)據(jù)，更新緩存
通過在集群中的每臺機器都部署一套定時任務(wù)，每隔一段時間就主動向數(shù)據(jù)庫DB請求最新數(shù)據(jù)，然后更新緩存。這樣做的好處是可以避免緩存擊穿的風(fēng)險，在緩存失效前就主動請求加載DB數(shù)據(jù)，完成緩存數(shù)據(jù)更新的無縫連接。
但這樣做也增加了機器的CPU和內(nèi)存的占用率，因為即使有若干Key的緩存始終不被訪問，可還是會被主動加載加載到內(nèi)存中。也就是說，提高了業(yè)務(wù)抗風(fēng)險能力，但對CPU和內(nèi)存資源并不友好。
詳情可參見下圖，分布式緩存中存儲著DB中的數(shù)據(jù)，每隔4.9s就會有定時任務(wù)執(zhí)行去更新緩存，而緩存數(shù)據(jù)失效時間為5s，從而保證緩存中的數(shù)據(jù)永遠存在，避免緩存擊穿的風(fēng)險。但對于Web請求來說，只會訪問k1的緩存數(shù)據(jù)，也即對于k2和k3數(shù)據(jù)來說，是無效緩存。
?
?
?
被動請求DB數(shù)據(jù)，更新緩存
當(dāng)有請求到達且發(fā)現(xiàn)緩存沒數(shù)據(jù)時，就向DB請求最新數(shù)據(jù)并更新緩存。這種方案完全可以看做是方案一的互斥方案，它解決的是機器CPU和內(nèi)存浪費的問題，內(nèi)存中存儲的數(shù)據(jù)始終是有用的，但卻無法避免緩存失效的瞬間又突然流量峰值帶來的緩存擊穿問題，在業(yè)務(wù)上會有一定的風(fēng)險。
詳情見下圖，緩存不會主動加載數(shù)據(jù)，而是根據(jù)Web請求懶加載數(shù)據(jù)。對于請求k1數(shù)據(jù)來說，發(fā)現(xiàn)緩存沒有對應(yīng)數(shù)據(jù)，到DB查詢，然后放入Cache，這是常規(guī)流程；但如果有突發(fā)流量，大量請求同時訪問k2數(shù)據(jù)，但Cache中沒有數(shù)據(jù)時，請求就會同時落到DB上，可能壓垮數(shù)據(jù)庫。
?
?
?
緩存過期策略
依賴時間的過期策略
* 定時刪除
對于需要刪除的每個Key都配備一個定時器，元素超時時間一到就刪除元素，釋放元素占用的內(nèi)存，同時釋放定時器自身資源。其優(yōu)點是元素的刪除很及時，但缺點也很明顯，比如為每個Key配備定時器肯定會消耗CPU和內(nèi)存資源，嚴重影響性能。這種策略只適合在小數(shù)據(jù)量且對過期時間又嚴格要求的場景能使用，一般生產(chǎn)環(huán)境都不會使用。
* 惰性刪除
元素過期后并不會立馬刪除，而是等到該元素的下一次操作（如：訪問、更新等）才會判斷是否過期，執(zhí)行過期刪除操作。這樣的好處是節(jié)約CPU資源，因為只有當(dāng)元素真的過期了，才會將其刪除，而不用單獨管理元素的生命周期。但其對內(nèi)存不友好，因為如果若干已經(jīng)過期的元素一直不被訪問的話，那就會一直占用內(nèi)存，造成內(nèi)存泄漏。
* 定期刪除
以上兩種元素刪除策略各有優(yōu)缺點，無非是對CPU友好，還是對內(nèi)存友好。為了結(jié)合兩者的優(yōu)點，一方面減少了元素定時器的配備，只使用一個定時器來統(tǒng)一掃描過期元素；另一方面加速了判斷元素過期的時間間隔，不是被動等待檢測過期，而是間隔一段時間就主動執(zhí)行元素過期檢測任務(wù)。正是由于以上的改進點，此方案是元素過期檢測的慣常手段。
我們假設(shè)一個場景，為了保護用戶隱私，通常在用戶電話和商家電話之間，會使用一個虛擬電話作為溝通的橋梁。業(yè)務(wù)使用中，往往同一個虛擬號碼在一定時間內(nèi)是可以對相同的用戶和商家建立連接的，而當(dāng)超出這個時間后，這個虛擬號碼就不再維護映射關(guān)系了。
虛擬電話號碼的資源是有限的，自然會想到創(chuàng)建一個虛擬號碼資源池，管理虛擬號碼的創(chuàng)建和釋放。比如規(guī)定一個虛擬號碼維持的關(guān)系每次能使用15分鐘，那么過期后要釋放虛擬號碼，我們有什么方案呢？
A. 方案一：全量數(shù)據(jù)掃描，依次遍歷判斷過期時間
?
?
?
對于DB中存儲的以上內(nèi)容，每天記錄都存儲著虛擬號碼的創(chuàng)建時間，以及經(jīng)過expire_seconds就會刪除此記錄。那么需要配備一個定時任務(wù)掃描表中的所有記錄，再判斷current_time
- create_time >expire_seconds，才會刪除記錄。
如果數(shù)據(jù)量很大的情況，就會導(dǎo)致數(shù)據(jù)刪除延遲時間很長，這并不是可取的方案。那是否有方案能直接獲取到需要過期的vr_phone，然后批量過期來解決上述痛點呢？來看看方案二吧。
B. 方案二：存儲絕對過期時間+BTree索引，批量獲取過期的vr_phone列表
?
?
?
將相對過期時間expire_seconds改為記錄過期的時間戳expire_timestamp，同時將其添加BTree索引提高檢索效率。仍然使用一個定時器，在獲取待刪除vr_phone列表時只需要select
vr_phone from table where now()>=expire_timestamp即可。
對于空間復(fù)雜度增加了一個BTree數(shù)據(jù)結(jié)構(gòu)，而基于BTree來考慮時間復(fù)雜度的話，對于元素的新增、修改、刪除、查詢的平均時間復(fù)雜度都是O(logN)。
此方案已經(jīng)能滿足業(yè)務(wù)使用需求了，那是否還有性能更好的方案呢？
d) 單層定時輪算法
我們繼續(xù)討論上面的案例，尋找更優(yōu)的解題思路。下表是DB存儲元素：
?
?
?
此時DB中不再存儲和過期時間相關(guān)的數(shù)據(jù)，而專注于業(yè)務(wù)數(shù)據(jù)本身。對于過期的功能我們交給單層定時輪來解決。其本質(zhì)是一個環(huán)形數(shù)組，數(shù)組每一格代表1秒，每次新加入的元素放在游標(biāo)的上一格，而游標(biāo)所指向的位置就是需要過期的vr_phone列表。
執(zhí)行過程：
1、初始化：啟動一個timer，每隔1s，在上述環(huán)形隊列中移動一格，1->2->3...->29->750->1...有一個指針來標(biāo)識有待過期的slot數(shù)據(jù)
2、新增數(shù)據(jù)：當(dāng)有一個新的vr_phone創(chuàng)建時，存儲到指針的上一個slot中。對于有slot沖突的場景，可以利用鏈表解決沖突，也可以利用數(shù)組解決沖突。鏈表和數(shù)組的考量標(biāo)準還是依賴于單個slot的數(shù)據(jù)長度，如果數(shù)據(jù)過長，那么存儲的數(shù)組會很長，則需要很大的內(nèi)存空間才能滿足，無法利用內(nèi)存碎片的空間。
3、過期數(shù)據(jù)：指針每隔1秒移動一個slot，那么指針指向的slot就是需要過期的數(shù)據(jù)，因為新增的數(shù)據(jù)在環(huán)形slot轉(zhuǎn)完一圈后，才會被指向到。
?
?
?
這樣一種算法結(jié)構(gòu)，將時間和空間巧妙地結(jié)合在了一起。新增元素的時間復(fù)雜度為O(1)，直接插入待批量過期的slot的上一個位置即可；獲取待刪除元素列表時間復(fù)雜度也是O(1)，就是待批量過期的slot位置。流行框架Netty、Kafka都有定時輪的影子。
當(dāng)然，單層定時輪只適用于固定時間過期的場景，如果需要管理不同過期時間的元素，那么可以參考"多層定時輪算法"，其實就是模擬現(xiàn)實世界的時針、分針、秒針的概念，建立多個單層定時輪，采用進位和退位的思想來管理元素的過期時間。
以上各種元素過期策略各有優(yōu)缺點，可以根據(jù)業(yè)務(wù)的訴求來取舍。比如Memcache只是用了惰性刪除，而Redis則同時使用了惰性刪除和定期刪除以結(jié)合二者的優(yōu)點。
依賴空間的過期策略
此處只探討最經(jīng)典的三種策略FIFO、LRU、LFU的原理及實現(xiàn)方案，對于其它改進算法，感興趣的同學(xué)可以自行查找。
a)
FIFO：先進先出，當(dāng)空間不足時，先進入的元素將會被移除。此方案并沒有考慮元素的使用特性，可能最近頻繁訪問的一個元素會被移除，從而降低了緩存命中率。實現(xiàn)：基于LinkedHashMap的鉤子函數(shù)實現(xiàn)FIFOMap。
// 鏈表頭部是最近最少被訪問的元素，需要被刪除 public class FIFOMap<K, V> extends LinkedHashMap<K, V>
{private int maxSize; //
LinkedHashMap每次插入數(shù)據(jù)，默認都是鏈表tail；當(dāng)accessOrder=false，元素被訪問不會移動位置 public FIFOMap(int
maxSize) { super(maxSize,0.75f, false); this.maxSize = maxSize; } //
每次put和putAll新增元素的時候都會觸發(fā)判斷;當(dāng)下面函數(shù)=true時，就刪除鏈表head元素 @Override protected boolean
removeEldestEntry(Map.Entry<K, V> eldest) { return size() > maxSize; } }
?
b)
LRU：最近最少使用算法，當(dāng)下多次被訪問的數(shù)據(jù)在以后被訪問的概率會很大，因此保留最近訪問的元素，提高命中率?？梢詰?yīng)對流量突發(fā)峰值，因為存儲的池子大小是固定的，因此內(nèi)存占用不可能過多。但也有缺點：如果一個元素訪問存在間歇規(guī)律，1分鐘前訪問1萬次，后面30秒無訪問，然后再訪問一萬次，這樣就會導(dǎo)致被刪除，降低了命中率。實現(xiàn)：基于LinkedHashMap的鉤子函數(shù)實現(xiàn)LRUHashMap。
// 鏈表頭部是最近最少被訪問的元素，需要被刪除 public class LRUMap<K, V> extends LinkedHashMap<K, V>
{private int maxSize; //
LinkedHashMap每次插入數(shù)據(jù)，默認都是鏈表tail；當(dāng)accessOrder=true時，被訪問的元素也會放到鏈表tail public
LRUMap(int maxSize) { super(maxSize, 0.75f, true); this.maxSize = maxSize; } //
每次put和putAll新增元素的時候都會觸發(fā)判斷;當(dāng)下面函數(shù)=true時，就刪除鏈表head元素 @Override protected boolean
removeEldestEntry(Map.Entry<K, V> eldest) { return size() >= maxSize; } }
?
?
c)
LFU：最近最少頻率使用，根據(jù)數(shù)據(jù)的歷史訪問頻率來淘汰數(shù)據(jù)，其核心思想是"如果數(shù)據(jù)過去被訪問多次，那么將來被訪問的頻率也更高"。這種算法針對LRU的缺點進行了優(yōu)化，記錄了元素訪問的總次數(shù)，選出訪問次數(shù)最小的元素進行刪除。原本的LFU算法要求記錄所有元素的訪問次數(shù)，但考慮到內(nèi)存成本，改進后的LFU是在有限隊列中進行淘汰。
實現(xiàn)：Redis的優(yōu)先級隊列Zset實現(xiàn)，Zset存儲元素的數(shù)量固定，Value是訪問次數(shù)，超過size就刪除訪問次數(shù)最小的即可。但這種刪除策略對于有時效性的數(shù)據(jù)卻并不合適，對于排行榜類的數(shù)據(jù)，如果某個歷史劇點擊量特別高，那么就始終不會被淘汰，新劇就沒有展示的機會。改進方案，可以將Value存儲為入庫時間戳+訪問次數(shù)的值，這樣隨著時間流逝，歷史老劇就可能被淘汰。
其他影響命中率的因素
緩存穿透
對于數(shù)據(jù)庫中本就不存在的值，緩存中肯定也不會存在，此類數(shù)據(jù)的查詢一定會落到DB上。為了減少DB訪問壓力，我們期望將這些數(shù)據(jù)都可以在緩存中cover住，以下是兩種解法。
*
解法一：緩存null值： 該方法對于元素是否存在于DB有精準的判斷，可如果存在海量null值的數(shù)據(jù)，則會對內(nèi)存過度占用。
*
布隆過濾： 使用場景是海量數(shù)據(jù)，且不要求精準判斷和過濾數(shù)據(jù)。其思路是借助Hash和bit位思想，將Key值映射成若干Hash值存儲到bit數(shù)組中。
?
?
?
B. 新增元素時，將元素的Key根據(jù)預(yù)設(shè)的若干Hash函數(shù)解析成若干整數(shù)，然后定位到bit位數(shù)組中，將對應(yīng)的bit位都改為1。
?
?
?
C.
判斷元素是否存在，也是將元素的Key根據(jù)Hash函數(shù)解析成整數(shù)，查詢?nèi)舾蒪it位的值。只要有一個bit位是0，那么這個Key肯定是新元素，不存在；如果所有bit位全都是1，那么這個Key很大概率是已經(jīng)存在的元素，但也有極小的概率是Key3經(jīng)過若干Hash函數(shù)定位到bit數(shù)組后都是Hash沖突的，可能造成誤判。
?
?
?
緩存擊穿
緩存中原本一批數(shù)據(jù)有值，但恰好都同時過期了，此時有大量請求過來就都會落到DB上。避免這種風(fēng)險也有兩種解法。
*
解法一：隨機緩存失效時間： 對緩存中不同的Key設(shè)置不同的緩存失效時間，避免緩存同時失效帶來大量請求都落到DB上的情況。
*
解法二：主動加載更新緩存策略，替代緩存過期刪除策略： 在緩存失效之前就主動到DB中加載最新的數(shù)據(jù)放到緩存中，從而避免大量請求落到DB的情況。
緩存雪崩
大量緩存同時過期，或者緩存中間件不可用，導(dǎo)致大量請求落到DB，系統(tǒng)停止響應(yīng)。解法是對緩存設(shè)置隨機失效時間，同時增加緩存中間件健康度監(jiān)測。
保證業(yè)務(wù)數(shù)據(jù)一致性的策略
在分析了影響緩存命中率的若干策略和方案后，我們結(jié)合實際開發(fā)訴求，來分析下緩存是如何降低DB的訪問壓力，以及DB和緩存中業(yè)務(wù)數(shù)據(jù)的一致性如何保證？
維護數(shù)據(jù)一致性常用的方案有兩種：先操作DB，再操作Cache；先操作Cache，再操作DB。而以上兩步操作都期望是全部成功，才能保證操作是原子性的。如果不依賴事務(wù)，那么對數(shù)據(jù)怎樣操作才能保證即使流程異常中斷，對業(yè)務(wù)影響也是最小呢？
對于讀取操作
因為只是讀取，不涉及數(shù)據(jù)修改，因此先讀緩存，Cache miss后，讀DB數(shù)據(jù)，然后set cache就足夠通用。
對于寫入操作
先操作DB，再操作(delete/update)緩存
當(dāng)DB數(shù)據(jù)操作成功，但緩存數(shù)據(jù)（不論是delete還是update）操作失敗，就會導(dǎo)致在未來一段時間內(nèi)，緩存中的數(shù)據(jù)都是歷史舊數(shù)據(jù)，并沒有保證操作的原子性，無法接受。
先操作(delete/update)緩存，再操作DB
*
第一種方案：當(dāng)update緩存成功，但操作DB失敗，雖然緩存中的數(shù)據(jù)是最新的了，但這個最新的數(shù)據(jù)最終并沒有更新到DB中，當(dāng)緩存失效后，還是會從DB中讀取到舊的數(shù)據(jù)，這樣就會導(dǎo)致上下游依賴的數(shù)據(jù)出現(xiàn)錯誤，無法接受。
*
第二種方案：先delete緩存，再操作DB數(shù)據(jù)，我們詳細討論下這種方案：
* 如果delete就失敗了，整體操作失敗，相當(dāng)于事務(wù)回滾；
* 如果delete成功，但DB操作失敗，此時會引起一次cache
miss，緊接著還是會從DB加載舊數(shù)據(jù)，相當(dāng)于整體無操作，事務(wù)回滾，代價只是一次cache miss；
* 如果delete成功，且DB操作成功，那么整體成功。
結(jié)論：先delete緩存，再操作DB，能盡可能達到兩步處理的原子性效果，即使流程中斷對業(yè)務(wù)影響也是最小的。
小結(jié)
對于緩存的使用沒有絕對的黃金標(biāo)準，都是根據(jù)業(yè)務(wù)的使用場景來決定什么緩存框架或者緩存策略是最適合的。但對于通用的業(yè)務(wù)場景來說，以下的緩存框架選擇方法應(yīng)該可以滿足大部分場景。
* 對于本地緩存，如果緩存的數(shù)量是可估計的，且不會變化的，那么可使用JDK自帶的HashMap或ConcurrentHashMap來存儲。
* 對于有按時間過期、自動刷新需求的本地緩存可以使用Caffeine。
* 對于分布式緩存且要求有豐富數(shù)據(jù)結(jié)構(gòu)的，推薦使用Redis。
?
?
?
關(guān)注高德技術(shù)，找到更多出行技術(shù)領(lǐng)域?qū)I(yè)內(nèi)容
?
熱門工具 換一換