按照現在流行的互聯網分層架構模型，最簡單的架構當屬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)，
如有更多技術疑問，大家可以可以加入到架構技術交流群進行一步的交流，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/42025.html
標籤：架構設計