緩存技術使用的實踐思考分析

緣起：為何使用緩存

在應用對外提供服務時，其穩定性受到諸多因素影響，其中比較重要的有CPU、記憶體、IO(磁碟IO、網路IO)等，這些硬體資源十分寶貴，因此對於那些需要經過複雜計算才能得到結果的，或者需要頻繁讀取磁碟數據的，最好將結果緩存起來，避免資源的重覆消耗。

CPU瓶頸

如果項目中有很多正則表達式計算，或者某個計算結果是多次中間結果合併後才得出的，且CPU的使用率一直居高不下，那麼就可以考慮是否應該將這些結果緩存起來，根據特定Key直接獲取Value結果，減少中間鏈路的傳遞過程，減少CPU的使用率。

IO瓶頸

眾所周知，從磁碟獲取數據受到磁碟轉速、尋道速度、磁碟緩衝區大小等諸多因素影響，這些因素決定了磁碟的IOPS，同時我們也知道對於數據的讀寫來說，CPU的緩存讀寫速度> 記憶體的讀寫速度>磁碟的讀寫速度。雖然磁碟內部也配備了緩存以匹配記憶體的讀寫速度，但其容量畢竟是有限的，那麼當磁碟的IOPS無法進一步提升的時候，便會想到將數據緩存到記憶體中，從而降低磁碟的訪問壓力。這一策略常被應用於緩解DB資料庫的數據訪問壓力。

選擇本地緩存和分散式緩存的考量點

既然可以使用緩存來提升系統吞吐能力，那麼緊接著遇到的問題就是選擇本地緩存，還是分散式緩存？什麼時候需要使用多級緩存呢？接下來，讓我們聊一聊在使用緩存優化項目的過程中，本地緩存和分散式緩存的應用場景和優缺點。

本地緩存的優缺點和應用場景

統一進程帶來了以下優勢：

• 由於本地緩存和應用在同一個進程中，因而其穩定性很高，達到了和應用同生共死的境界；
• 由於在同一進程中，避免了網路數據傳輸帶來的消耗，所有緩存數據直接從進程所在的記憶體區域獲取即可。

強耦合性也會導致以下這些劣勢：

• 本地緩存和應用共用一片記憶體，爭搶記憶體資源，無法水平擴展，且可能造成頻繁的GC，影響線上應用的穩定性。
• 由於沒有持久化機制，在項目重啟後緩存內數據就會丟失，對於高頻訪問數據，需要對數據進行預熱操作。
• 多份進程內緩存存儲著同樣的數據內容，造成記憶體使用浪費。
• 同樣的數據存儲在不同的本地機器，數據變化後，很難保證數據的一致性。

結合以上優缺點，我們就會想到，如果有一種數據需要頻繁訪問，但一旦創建後就輕易不會改變，而且初始創建時就能預估占用的記憶體空間，那麼這種類型的數據無疑是最適合用本地緩存存儲了。

既然有了上述的應用場景，反觀技術開發中的訴求，發現其實很多優秀的框架已經在這樣使用了，比如緩存類class的反射信息，包括field、method等。因為class的數量是有限的，且內容不會輕易改變，在使用時無需再使用反射機制，而只需要從本地緩存讀取數據即可。

分散式緩存的優缺點和應用場景

優勢：

• 數據集中存儲，消除冗餘數據，解決整體記憶體的占用率，易於維護集群建緩存數據的一致性。
• 緩存中間件可以對緩存進行統一管理，便於水平擴容。

劣勢：

• 依賴分散式緩存中間件穩定性，一旦掛了，容易造成緩存雪崩；
• 由於是跨機器獲取緩存數據，因此會造成數據傳輸的網路消耗，以及一些序列化/反序列化的時間開銷。

對於上述缺點中，網路耗時等開銷是難免的，而且這些操作耗費的時間在可接受範圍內，而對於中間件的穩定性則可以通過服務降級、限流或者多級緩存思路來保證。主要看中的是它的優點，既然分散式緩存天然能保證緩存一致性，那麼我們傾向於將需要頻繁訪問卻又經常變化的數據存放於此。

緩存框架使用過程的註意點

不論是本地緩存還是分散式緩存，在使用緩存提升性能的時候，必然會考慮緩存命中率的高低，考慮緩存數據的更新和刪除策略，考慮數據一致性如何維護，本小節主要針對以上的問題來分析不同實現方案的優缺點。

緩存命中率

緩存命中率不僅是系統性能的一個側面指標，也是優化緩存使用方案的一個重要依據。緩存命中率=請求命中數/請求總數。接下來的若幹緩存使用策略所圍繞的核心考量點就是在保證系統穩定性的同時，旨在提升緩存命中率。

緩存更新策略

主動請求DB數據，更新緩存

通過在集群中的每台機器都部署一套定時任務，每隔一段時間就主動向資料庫DB請求最新數據，然後更新緩存。這樣做的好處是可以避免緩存擊穿的風險，在緩存失效前就主動請求載入DB數據，完成緩存數據更新的無縫連接。

但這樣做也增加了機器的CPU和記憶體的占用率，因為即使有若幹Key的緩存始終不被訪問，可還是會被主動載入載入到記憶體中。也就是說，提高了業務抗風險能力，但對CPU和記憶體資源並不友好。

詳情可參見下圖，分散式緩存中存儲著DB中的數據，每隔4.9s就會有定時任務執行去更新緩存，而緩存數據失效時間為5s，從而保證緩存中的數據永遠存在，避免緩存擊穿的風險。但對於Web請求來說，只會訪問k1的緩存數據，也即對於k2和k3數據來說，是無效緩存。

被動請求DB數據，更新緩存

當有請求到達且發現緩存沒數據時，就向DB請求最新數據並更新緩存。這種方案完全可以看做是方案一的互斥方案，它解決的是機器CPU和記憶體浪費的問題，記憶體中存儲的數據始終是有用的，但卻無法避免緩存失效的瞬間又突然流量峰值帶來的緩存擊穿問題，在業務上會有一定的風險。

詳情見下圖，緩存不會主動載入數據，而是根據Web請求懶載入數據。對於請求k1數據來說，發現緩存沒有對應數據，到DB查詢，然後放入Cache，這是常規流程；但如果有突發流量，大量請求同時訪問k2數據，但Cache中沒有數據時，請求就會同時落到DB上，可能壓垮資料庫。

緩存過期策略

依賴時間的過期策略

• 定時刪除

對於需要刪除的每個Key都配備一個定時器，元素超時時間一到就刪除元素，釋放元素占用的記憶體，同時釋放定時器自身資源。其優點是元素的刪除很及時，但缺點也很明顯，比如為每個Key配備定時器肯定會消耗CPU和記憶體資源，嚴重影響性能。這種策略只適合在小數據量且對過期時間又嚴格要求的場景能使用，一般生產環境都不會使用。

• 惰性刪除

元素過期後並不會立馬刪除，而是等到該元素的下一次操作（如：訪問、更新等）才會判斷是否過期，執行過期刪除操作。這樣的好處是節約CPU資源，因為只有當元素真的過期了，才會將其刪除，而不用單獨管理元素的生命周期。但其對記憶體不友好，因為如果若幹已經過期的元素一直不被訪問的話，那就會一直占用記憶體，造成記憶體泄漏。

• 定期刪除

以上兩種元素刪除策略各有優缺點，無非是對CPU友好，還是對記憶體友好。為了結合兩者的優點，一方面減少了元素定時器的配備，只使用一個定時器來統一掃描過期元素；另一方面加速了判斷元素過期的時間間隔，不是被動等待檢測過期，而是間隔一段時間就主動執行元素過期檢測任務。正是由於以上的改進點，此方案是元素過期檢測的慣常手段。

我們假設一個場景，為了保護用戶隱私，通常在用戶電話和商家電話之間，會使用一個虛擬電話作為溝通的橋梁。業務使用中，往往同一個虛擬號碼在一定時間內是可以對相同的用戶和商家建立連接的，而當超出這個時間後，這個虛擬號碼就不再維護映射關係了。

虛擬電話號碼的資源是有限的，自然會想到創建一個虛擬號碼資源池，管理虛擬號碼的創建和釋放。比如規定一個虛擬號碼維持的關係每次能使用15分鐘，那麼過期後要釋放虛擬號碼，我們有什麼方案呢？

A. 方案一：全量數據掃描，依次遍歷判斷過期時間

對於DB中存儲的以上內容，每天記錄都存儲著虛擬號碼的創建時間，以及經過expire_seconds就會刪除此記錄。那麼需要配備一個定時任務掃描表中的所有記錄，再判斷current_time - create_time >expire_seconds，才會刪除記錄。

如果數據量很大的情況，就會導致數據刪除延遲時間很長，這並不是可取的方案。那是否有方案能直接獲取到需要過期的vr_phone，然後批量過期來解決上述痛點呢？來看看方案二吧。

B.方案二：存儲絕對過期時間+BTree索引，批量獲取過期的vr_phone列表

將相對過期時間expire_seconds改為記錄過期的時間戳expire_timestamp，同時將其添加BTree索引提高檢索效率。仍然使用一個定時器，在獲取待刪除vr_phone列表時只需要select vr_phone from table where now()>=expire_timestamp即可。

對於空間複雜度增加了一個BTree數據結構，而基於BTree來考慮時間複雜度的話，對於元素的新增、修改、刪除、查詢的平均時間複雜度都是O(logN)。