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