系統效能提升利刃 | 快取技術使用的實踐與思考

amap_tech發表於2019-08-15
快取

導讀

按照現在流行的網際網路分層架構模型，最簡單的架構當屬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資料，我們詳細討論下這種方案：

  1. 如果delete就失敗了，整體操作失敗，相當於事務回滾；
  2. 如果delete成功，但DB操作失敗，此時會引起一次cache miss，緊接著還是會從DB載入舊資料，相當於整體無操作，事務回滾，代價只是一次cache miss；
  3. 如果delete成功，且DB操作成功，那麼整體成功。

結論：先delete快取，再操作DB，能儘可能達到兩步處理的原子性效果，即使流程中斷對業務影響也是最小的。

小結

對於快取的使用沒有絕對的黃金標準，都是根據業務的使用場景來決定什麼快取框架或者快取策略是最適合的。但對於通用的業務場景來說，以下的快取框架選擇方法應該可以滿足大部分場景。

  • 對於本地快取，如果快取的數量是可估計的，且不會變化的，那麼可使用JDK自帶的HashMap或ConcurrentHashMap來儲存。
  • 對於有按時間過期、自動重新整理需求的本地快取可以使用Caffeine。
  • 對於分散式快取且要求有豐富資料結構的，推薦使用Redis。


關注高德技術，找到更多出行技術領域專業內容


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69941357/viewspace-2653758/，如需轉載，請註明出處，否則將追究法律責任。

相關文章