開篇寄語：緩存，你真的用對了嗎？

我們為什么要學習緩存呢？有必要學習緩存嗎？

緩存的使用，是提升系統性能、改善用戶體驗的唯一解決之道。

其實，作為互聯網公司，只要有直接面對用戶的業務，要想持續確保系統的訪問性能和可用性，都需要使用緩存。因此，緩存也是后端工程師面試中一個非常重要的考察點，面試官通常會通過應聘者對緩存相關知識的理解深入程度，來判斷其開發經驗和學習能力。可以說，對緩存的掌握程度，在某種意義上決定了后端開發者的職業高度。

想學好緩存，需要掌握哪些知識呢？

緩存知識點全景圖：

• 首先，要熟練掌握緩存的基礎知識，了解緩存常見的分類、讀寫模式，熟悉緩存的七大經典問題及解決應對之策，同時要從緩存組件的訪問協議、Client入手，熟練掌握如何訪問各種緩存組件，如Memcached、Redis、Pika等。
• 其次，要盡可能深入理解緩存組件的實現方案、設計原理，了解緩存的各種特性、優勢和不足，這樣在緩存數據與預期不一致時，能夠快速定位并解決問題。
• 再次，還要多了解線上大中型系統是如何對緩存進行架構設計的。線上系統，業務功能豐富多變，跨域部署環境復雜，而且熱點頻發，用戶習慣迥異。因此，緩存系統在設計之初就要盡量進行良好設計，規劃好如何進行Hash及分布、如何保障數據的一致性、如何進行擴容和縮容。當然，緩存體系也需要伴隨業務發展持續演進，這就需要對緩存體系進行持續的狀態監控、異常報警、故障演練，以確保在故障發生時能及時進行人肉或自動化運維處理，并根據線上狀態不斷進行優化和改進。
• 最后，了解存在各種場景下的最佳實踐，理解這些最佳實踐背后的Tradeoff，做到知其然知其所以然，以便在實際工作中能舉一反三，把知識和經驗更好的應用到工作實踐中來。

如何高效學習緩存呢？你能學到什么？

用 10 課時來分享：

• 如何更好地引入和使用緩存，自系統設計之初，就把緩存設計的關鍵點對號入座。
• 如何規避并解決緩存設計中的七大經典問題。
• 從協議、使用技巧、網絡模型、核心數據結構、存儲架構、數據處理模型、優化及改進方案等，多角度全方位深入剖析互聯網企業大量使用的Memcached、Redis等開源緩存組件。
• 教你如何利用它們構建一個分布式緩存服務體系。
• 最后，我將結合諸如秒殺、海量計數、微博 Feed 聚合等經典業務場景，分析如何構建相應的高可用、高性能、易擴展的緩存架構體系。
  通過本課程，你可以：

系統地學習緩存之設計架構的關鍵知識點；

• 學會如何更好地使用 Memcached、Redis 等緩存組件；
• 對這些緩存組件的內部架構、設計原理有一個較為深入的了解，真正做到知其然更知其所以然；
• 學會如何根據業務需要對緩存組件進行二次開發；
  搞懂如何構建一個大型的分布式緩存服務系統；
• 了解在當前多種熱門場景下緩存服務的最佳實踐；
• 現學現用，針對互聯網大中型系統，構建出一個更好的緩存架構體系，在大幅提升系統吞吐和響應性能的同時，達到高可用、高擴展，從而可以更從容地應對海量并發請求和極端熱點事件。

業務數據訪問性能太低怎么辦？

緩存的定義

廣義緩存時任何可以用于數據高速交換的存儲介質都是緩存，可以是硬件也可以是軟件。
緩存存在的意義就是通過開辟一個新的數據交換緩沖區，來解決原始數據獲取代價太大的問題，讓數據得到更快的訪問。

緩存的原理

緩存構建的基本思想是利用時間局限性原理，通過空間換時間來達到加速數據獲取的目的，同時由于緩存空間的成本較高，在實際設計架構中還要考慮訪問延遲和成本的權衡問題。這里面有 3 個關鍵點。

• 一是時間局限性原理，即被獲取過一次的數據在未來會被多次引用，比如一條微博被一個人感興趣并閱讀后，它大概率還會被更多人閱讀，當然如果變成熱門微博后，會被數以百萬/千萬計算的更多用戶查看。
• 二是以空間換時間，因為原始數據獲取太慢，所以我們開辟一塊高速獨立空間，提供高效訪問，來達到數據獲取加速的目的。
• 三是性能成本 Tradeoff，構建系統時希望系統的訪問性能越高越好，訪問延遲越低小越好。但維持相同數據規模的存儲及訪問，性能越高延遲越小，成本也會越高，所以在系統架構設計時，你需要在系統性能和開發運行成本之間做取舍。比如左邊這張圖，相同成本的容量，SSD 硬盤容量會比內存大 10～30 倍以上，但讀寫延遲卻高 50～100 倍。

緩存的優勢

緩存的優勢：

• 提升訪問性能
• 降低網絡擁堵
• 減輕服務負載
• 增強可擴展性

緩存的代價

• 首先，服務系統重引入緩存，會增加系統的復雜度。
• 其次，由于緩存相比原始 DB 存儲的成本更高，所以系統部署及運行的費用也會更高。
• 最后，由于一份數據同時存在緩存和 DB 中，甚至緩存內部也會有多個數據副本，多份數據就會存在一致性問題，同時緩存體系本身也會存在可用性問題和分區的問題。

如何根據業務來選擇緩存模式和組件？

緩存讀寫模式

業務系統讀寫緩存有 3 種模式：

• Cache Aside（旁路緩存）
• Read/Write Through（讀寫穿透）
• Write Behind Caching（異步緩存寫入）

Cache Aside

Cache Aside模式中，業務應用方對于寫，是更新DB后，直接將可以從cache中刪除，然后由DB驅動緩存數據的更新；而對于讀，是先讀cache，如果cache沒有，則讀DB，同時將從DB中讀取的數據回寫到cache。

這種模式的特點是，業務端處理所有數據訪問細節，同時利用Lazy計算的思想，更新DB后，直接刪除cache并通過DB更新，確保數據以DB結果為準，則可以大幅降低cache和DB中數據不一致的概率。

如果沒有專門的存儲服務，同時是對數據一致性要求比較高的業務，或者是緩存數據更新比較復雜的業務，這些情況都比較適合使用 Cache Aside 模式。如微博發展初期，不少業務采用這種模式，這些緩存數據需要通過多個原始數據進行計算后設置。在部分數據變更后，直接刪除緩存。同時，使用一個 Trigger 組件，實時讀取 DB 的變更日志，然后重新計算并更新緩存。如果讀緩存的時候，Trigger 還沒寫入 cache，則由調用方自行到 DB 加載計算并寫入 cache。

Read/Write Through

對于Cache Aside模式，業務應用需要同時維護cache和DB兩個數據存儲方，過于繁瑣，也是就有了Read/Write Through模式。在這種模式下，業務應用只關注一個存儲服務即可。業務方的讀寫cache和DB的操作，都由存儲服務代理。存儲服務收到業務應用的寫請求是，會首先查cache，如果數據在cache中不存在，則只更新DB，如果數據在cache中存在，則先更新cache，然后更新DB。而存儲服務收到讀請求時，如果命中 cache 直接返回，否則先從 DB 加載，回種到 cache 后返回響應。

這種模式的特點是，存儲服務封裝了所有的數據處理細節，業務應用端代碼只用關注業務邏輯本身，西戎的隔離性更佳。另外，進行寫操作時，如果cache中沒有數據則不更新，有緩存數據才更新，內存效率更高。

微博 Feed 的 Outbox Vector（即用戶最新微博列表）就采用這種模式。一些粉絲較少且不活躍的用戶發表微博后，Vector 服務會首先查詢 Vector Cache，如果 cache 中沒有該用戶的 Outbox 記錄，則不寫該用戶的 cache 數據，直接更新 DB 后就返回，只有 cache 中存在才會通過 CAS 指令進行更新。

Write Behind Caching

Write Behind Caching 模式與 Read/Write Through 模式類似，也由數據存儲服務來管理 cache 和 DB 的讀寫。不同點是，數據更新時，Read/Write Through是同步更新cache和DB，而Write Behind Caching則是只更新緩存，不直接更新DB，不直接更新DB，而是改為異步批量的方式來更新DB。該模式的特點是，數據存儲的寫性能最高，非常適合一些變更特別頻繁的業務，特別是可以合并寫請求的業務，比如對一些計數業務，一條 Feed 被點贊 1萬 次，如果更新 1萬 次 DB 代價很大，而合并成一次請求直接加 1萬，則是一個非常輕量的操作。但這種模型有個顯著的缺點，即數據的一致性變差，甚至在一些極端場景下可能會丟失數據。比如系統 Crash、機器宕機時，如果有數據還沒保存到 DB，則會存在丟失的風險。所以這種讀寫模式適合變更頻率特別高，但對一致性要求不太高的業務，這樣寫操作可以異步批量寫入 DB，減小 DB 壓力。

緩存的三種讀寫模式講完了，你可以看到三種模式各有優劣，不存在最佳模式。實際上，我們也不可能設計出一個最佳的完美模式出來，如同前面講到的空間換時間、訪問延遲換低成本一樣，高性能和強一致性從來都是有沖突的，系統設計從來就是取舍，隨處需要 trade-off。這個思想會貫穿整個 cache 課程，這也許是我們學習這個課程的另外一個收獲，即如何根據業務場景，更好的做 trade-off，從而設計出更好的服務系統。

緩存分類及常用緩存介紹

前面介紹了緩存的基本思想、優勢、代價以及讀寫模式，接下來一起看下互聯網企業常用的緩存有哪些分類。

按宿主層次分類

按宿主層次分類的話，緩存一般可以分為本地Cache、進程間Cache和遠程Cache。

• 本地Cache是指業務進程內的緩存，這類緩存由于在業務系統進程內，所以讀寫性能超高且無任何網絡開銷，但不足是會隨著業務系統重啟而丟失。
• 進程間Cache是本機獨立運行的緩存，這類緩存讀寫性能較高，不會隨著業務系統重啟丟數據，并且可以大幅減少網絡開銷，但不足是業務系統和緩存都在相同宿主機，運維復雜，且存在資源競爭。
• 遠程Cache是指跨機器部署的緩存，這類緩存因為獨立設備部署，容量大且易擴展，在互聯網企業使用最廣泛。不過遠程緩存需要跨機訪問，在高讀寫壓力下，帶寬容易成為瓶頸。

本地Cache的緩存組件有Ehache、Guava Cache等，開發者自己也可以用Map、Set等輕松構建一個自己專用的本地Cache。進程間Cache和遠程Cache的緩存組件相同，只是部署位置的差異罷了，這類緩存組件有Memcached、Redis、Pika等。

按存儲介質分類

按存儲介質來分，這樣可以分為內存型緩存和持久化型緩存。

• 內存型緩存將數據存儲在內存，讀寫性能很高，但緩存系統重啟或 Crash 后，內存數據會丟失。
• 持久化型緩存將數據存儲到 SSD/Fusion-IO 硬盤中，相同成本下，這種緩存的容量會比內存型緩存大 1 個數量級以上，而且數據會持久化落地，重啟不丟失，但讀寫性能相對低 1～2 個數量級。Memcached 是典型的內存型緩存，而 Pika 以及其他基于 RocksDB 開發的緩存組件等則屬于持久化型緩存。

設計緩存架構時需要考量哪些因素？

緩存的引入及架構設計

緩存組件選擇

在設計架構緩存時，你首先要選定緩存組件，比如要用 Local-Cache，還是 Redis、Memcached、Pika 等開源緩存組件，如果業務緩存需求比較特殊，你還要考慮是直接定制開發一個新的緩存組件，還是對開源緩存進行二次開發，來滿足業務需要。

緩存數據結構設計

根據業務訪問的特點，進行緩存數據結構的設計。對于直接簡單 KV 讀寫的業務，你可以將這些業務數據封裝為 String、Json、Protocol Buffer 等格式，序列化成字節序列，然后直接寫入緩存中。讀取時，先從緩存組件獲取到數據的字節序列，再進行反序列化操作即可。對于只需要存取部分字段或需要在緩存端進行計算的業務，你可以把數據設計為 Hash、Set、List、Geo 等結構，存儲到支持復雜集合數據類型的緩存中，如 Redis、Pika 等。

緩存分布設計

可以從3個維度來進行緩存分布設計。

1. 首先，要選擇分布式算法，是采用取模還是一致性 Hash 進行分布。取模分布的方案簡單，每個 key 只會存在確定的緩存節點，一致性 Hash 分布的方案相對復雜，一個 key 對應的緩存節點不確定。但一致性 Hash 分布，可以在部分緩存節點異常時，將失效節點的數據訪問均衡分散到其他正常存活的節點，從而更好地保證了緩存系統的穩定性。
2. 其次，分布讀寫訪問如何進行實施，是由緩存Client直接進行 Hash 分布定位讀寫，還是通過 Proxy 代理來進行讀寫路由？Client 直接讀寫，讀寫性能最佳，但需要 Client 感知分布策略。在緩存部署發生在線變化時，也需要及時通知所有緩存 Client，避免讀寫異常，另外，Client 實現也較復雜。而通過 Proxy 路由，Client 只需直接訪問 Proxy，分布邏輯及部署變更都由 Proxy 來處理，對業務應用開發最友好，但業務訪問多一跳，訪問性能會有一定的損失。
3. 最后，緩存系統運行過程中，如果待緩存的數據量增長過快，會導致大量緩存數據被剔除，緩存命中率會下降，數據訪問性能會隨之降低，這樣就需要將數據從緩存節點態拆分，把部分數據水平遷移到其他緩存節點。這個遷移過程需要考慮，是由 Proxy 進行遷移還是緩存 Server 自身進行遷移，甚至根本就不支持遷移。對于 Memcached，一般不支持遷移，對 Redis，社區版本是依靠緩存 Server 進行遷移，而對 Codis 則是通過 Admin、Proxy 配合后端緩存組件進行遷移。

緩存架構部署及運維管理

架構部署主要考慮如何對緩存進行分池、分層、分 IDC，以及是否需要進行異構處理。

1. 核心的、高并發訪問的不同數據，需要分別分拆到獨立的緩存池中，進行分別訪問，避免相互影響；訪問量較小、非核心的業務數據，則可以混存。
2. 對海量數據、訪問超過10~100萬級的業務數據，要考慮分層訪問，并且要分攤訪問量，避免緩存過載。
3. 如果業務系統需要多IDC部署甚至異地多活，則需要對緩存體系也進行多IDC部署，要考慮如何跨IDC對緩存數據進行更新，可以采用直接跨IDC讀寫，也可以采用DataBus配合隊列機進行不同 IDC 的消息同步，然后由消息處理機進行緩存更新，還可以由各個 IDC 的 DB Trigger 進行緩存更新。
4. 某些極端場景下，還需要把多種緩存組件進行組合使用，通過緩存異構達到最佳讀寫性能。
5. 站在系統層面，要想更好得管理緩存，還要考慮緩存的服務化，考慮緩存體系如何更好得進行集群管理、監控運維等。

IDC全稱為Internet Data Center，中文譯為“互聯網數據中心”，是提供服務器托管、網絡接入、電力供應、安全防護等服務的專業化機房設施。

緩存設計架構的常見考量點

在緩存設計架構的過程中，有一些非常重要的考量點，如下圖所示，只有分析清楚了這些考量點，才能設計架構出更佳的緩存體系。

讀寫方式

首先是 value 的讀寫方式。是全部整體讀寫，還是只部分讀寫及變更？是否需要內部計算？比如，用戶粉絲數，很多普通用戶的粉絲有幾千到幾萬，而大 V 的粉絲更是高達幾千萬甚至過億，因此，獲取粉絲列表肯定不能采用整體讀寫的方式，只能部分獲取。另外在判斷某用戶是否關注了另外一個用戶時，也不需要拉取該用戶的全部關注列表，直接在關注列表上進行檢查判斷，然后返回 True/False 或 0/1 的方式更為高效。

KV size

然后是不同業務數據緩存 KV 的 size。如果單個業務的 KV size 過大，需要分拆成多個 KV 來緩存。但是，不同緩存數據的 KV size 如果差異過大，也不能緩存在一起，避免緩存效率的低下和相互影響。

Key的數量

key 的數量也是一個重要考慮因素。如果 key 數量不大，可以在緩存中存下全量數據，把緩存當 DB 存儲來用，如果緩存讀取 miss，則表明數據不存在，根本不需要再去 DB 查詢。如果數據量巨大，則在緩存中盡可能只保留頻繁訪問的熱數據，對于冷數據直接訪問 DB。

讀寫峰值

另外，對緩存數據的讀寫峰值，如果小于 10萬 級別，簡單分拆到獨立 Cache 池即可。而一旦數據的讀寫峰值超過 10萬 甚至到達 100萬 級的QPS，則需要對 Cache 進行分層處理，可以同時使用 Local-Cache 配合遠程 cache，甚至遠程緩存內部繼續分層疊加分池進行處理。微博業務中，大多數核心業務的 Memcached 訪問都采用的這種處理方式。

命中率

緩存的命中率對整個服務體系的性能影響甚大。對于核心高并發訪問的業務，需要預留足夠的容量，確保核心業務緩存維持較高的命中率。比如微博中的 Feed Vector Cache，常年的命中率高達 99.5% 以上。為了持續保持緩存的命中率，緩存體系需要持續監控，及時進行故障處理或故障轉移。同時在部分緩存節點異常、命中率下降時，故障轉移方案，需要考慮是采用一致性 Hash 分布的訪問漂移策略，還是采用數據多層備份策略。

過期策略

• 可以設置較短的過期時間，讓冷key自動過期；
• 也可以讓key帶上時間戳，同時設置較長的過期時間，比如很多業務系統內部都由這樣一些key：key_20190801。

平均緩存穿透加載時間

平均緩存穿透加載時間在某些業務場景下也很重要，對于一些緩存穿透后，加載時間特別長或者需要復雜計算的數據，而且訪問量還比較大的業務數據，要配置更多容量，維持更高的命中率，從而減少穿透到 DB 的概率，來確保整個系統的訪問性能。

緩存可運維性

對于緩存的可運維性考慮，則需要考慮緩存體系的集群管理，如何進行一鍵擴縮容，如何進行緩存組件的升級和變更，如何快速發現并定位問題，如何持續監控報警，最好有一個完善的運維平臺，將各種運維工具進行集成。

緩存安全性

對于緩存的安全性考慮，一方面可以限制來源 IP，只允許內網訪問，同時對于一些關鍵性指令，需要增加訪問權限，避免被攻擊或誤操作時，導致重大后果。