學習筆記 | 緩存的原理、引入和設計

01 緩存的定義

• 緩存最初的含義，是指用於加速 CPU 數據交換的 RAM，即隨機存取存儲器，通常這種存儲器使用更昂貴但快速的靜態 RAM（SRAM）技術，用以對 DRAM進 行加速。這是一個狹義緩存的定義。
• 而廣義緩存的定義則更寬泛，任何可以用於數據高速交換的存儲介質都是緩存，可以是硬件也可以是軟件。
• 緩存存在的意義就是通過開闢一個新的數據交換緩衝區，來解決原始數據獲取代價太大的問題，讓數據得到更快的訪問。
  

02 緩存的基本思想

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

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

03 緩存的優勢

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

04 緩存的代價

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

05 緩存的讀寫模式及分類

緩存分類 | 按宿主層次分類

• 按宿主層次分類的話，緩存一般可以分爲本地 Cache、進程間 Cache 和遠程 Cache。
• 本地 Cache 是指業務進程內的緩存，這類緩存由於在業務系統進程內，所以讀寫性能超高且無任何網絡開銷，但不足是會隨着業務系統重啓而丟失。
• 進程間 Cache 是本機獨立運行的緩存，這類緩存讀寫性能較高，不會隨着業務系統重啓丟數據，並且可以大幅減少網絡開銷，但不足是業務系統和緩存都在相同宿主機，運維複雜，且存在資源競爭。
• 遠程 Cache 是指跨機器部署的緩存，這類緩存因爲獨立設備部署，容量大且易擴展，在互聯網企業使用最廣泛。不過遠程緩存需要跨機訪問，在高讀寫壓力下，帶寬容易成爲瓶頸。
• 本地 Cache 的緩存組件有 Ehcache、Guava Cache 等，開發者自己也可以用 Map、Set 等輕鬆構建一個自己專用的本地 Cache。進程間 Cache 和遠程 Cache 的緩存組件相同，只是部署位置的差異罷了，這類緩存組件有 Memcached、Redis、Pika 等。

緩存分類 | 按存儲介質分類

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

讀寫方式

• 首先是 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，只允許內網訪問，同時對於一些關鍵性指令，需要增加訪問權限，避免被攻擊或誤操作時，導致重大後果。