按照現在流行的互聯網分層架構模型，最簡單的架構當屬Web響應層+DB存儲層的架構。從最開始的單機混合部署Web和DB，到後來將二者拆分到不同物理機以避免共享機器硬體帶來的性能瓶頸，再隨著流量的增長，Web應用變為集群部署模式，而DB則衍生出主從機來保證高可用，同時便於實現讀寫分離。這一連串系統架構的升級，本質上是為了追求更高的性能，達到更低的延時。

緣起：為何使用快取

在應用對外提供服務時，其穩定性受到諸多因素影響，其中比較重要的有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)。