系統性能提高利刃 | 緩存技術使用的實踐與思考

時間 2019-11-06

原文原文鏈接

導讀

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

高德做爲一款國民級別的導航軟件，導航路線的數據質量是由數據中心統一管理的。爲了保證數據的鮮度，數據中心須要對不斷變化的現實道路數據進行收集，將這些變化的信息保存到數據庫中，從而保證導航數據的鮮度；另外一方面數據中心內部多部門協調生產數據的時候，會產生海量請求查詢最新生產的數據，這就要求數據的管理者要控制數據庫鏈接數，下降請求的響應耗時，同時也須要保證返回數據的實時性。算法

在平衡數據鮮度和性能之間，高德數據中心針對不一樣的業務場景使用了不一樣的策略，達到了數據變動和緩存同步低延遲的目標，同時保障了系統的穩定性。數據庫

本文將說起的緩存技術則是提高性能的另外一把利刃。然而任何技術都是有可爲有可不爲，沒有最好的技術只有最適合的技術，所以在使用緩存以前，咱們也須要了解下引入緩存模塊所帶來的好處和壞處。數組

緣起：爲什麼使用緩存

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

CPU瓶頸bash

若是項目中有不少正則表達式計算，或者某個計算結果是屢次中間結果合併後才得出的，且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列表。

執行過程：

一、初始化：啓動一個timer，每隔1s，在上述環形隊列中移動一格，1->2->3...->29->750->1...有一個指針來標識有待過時的slot數據

二、新增數據：當有一個新的vr_phone建立時，存儲到指針的上一個slot中。對於有slot衝突的場景，能夠利用鏈表解決衝突，也能夠利用數組解決衝突。鏈表和數組的考量標準仍是依賴於單個slot的數據長度，若是數據過長，那麼存儲的數組會很長，則須要很大的內存空間才能知足，沒法利用內存碎片的空間。

三、過時數據：指針每隔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衝突的，可能形成誤判。