這波舒服了,落地多級緩存!
你好呀，我是歪歪。
最近在有贊技術團隊的博客上看到一篇關于多級緩存的文章，覺得非常的不錯。
其實這篇文章我很久之前就看過了，看完之后只是知道有這樣的一個東西，但是也沒有細細的思考研究。
最近剛好關于熱點數(shù)據(jù)探測這方面有一點自己的思考，再次讀這篇文章的時候就感覺收獲頗豐。
大家都知道，分布式服務的三大利器就是：
拆分、緩存、加錢。
緩存的重要性不言而喻。
而多級緩存對于不可預測的、慢熱事件頻發(fā)的系統(tǒng)的穩(wěn)定性是一個強有力的保障。
但是多級緩存解決方案的痛點也非常的明顯比如：
- 熱點探測：如何快速且準確的發(fā)現(xiàn)熱點訪問key？
- 數(shù)據(jù)一致性：前置在應用層的本地緩存，如何保障與分布式緩存系統(tǒng)的數(shù)據(jù)一致性？
- 效果驗證：如何讓應用層查看本地緩存命中率、熱點key等數(shù)據(jù)，驗證多級緩存效果？
- 透明接入：整體解決方案如何減少對應用系統(tǒng)的入侵，做到快速平滑接入？
針對上述痛點，有贊設計并實現(xiàn)了整套的解決方案。
可以支持“熱點探測”和“本地緩存”，減少熱點訪問時對下游分布式緩存服務的沖擊，避免影響應用服務的性能及穩(wěn)定性。
那么到底是怎么實現(xiàn)的呢？
走，一起去看看。
- 原文鏈接：https://tech.youzan.com/tmc/
一、引子
TMC 是什么
TMC，即“透明多級緩存（Transparent Multilevel Cache）”，是有贊 PaaS 團隊給公司內(nèi)應用提供的整體緩存解決方案。
TMC 在通用“分布式緩存解決方案（如 CodisProxy + Redis，如有贊自研分布式緩存系統(tǒng) zanKV）”基礎上，增加了以下功能：
- 應用層熱點探測
- 應用層本地緩存
- 應用層緩存命中統(tǒng)計
以幫助應用層解決緩存使用過程中出現(xiàn)的熱點訪問問題。
為什么要做 TMC
使用有贊服務的電商商家數(shù)量和類型很多，商家會不定期做一些“商品秒殺”、“商品推廣”活動，導致“營銷活動”、“商品詳情”、“交易下單”等鏈路應用出現(xiàn)緩存熱點訪問的情況：
- 活動時間、活動類型、活動商品之類的信息不可預期，導致緩存熱點訪問 情況不可提前預知。
- 緩存熱點訪問出現(xiàn)期間，應用層少數(shù)熱點訪問 key產(chǎn)生大量緩存訪問請求：沖擊分布式緩存系統(tǒng)，大量占據(jù)內(nèi)網(wǎng)帶寬，最終影響應用層系統(tǒng)穩(wěn)定性；
為了應對以上問題，需要一個能夠自動發(fā)現(xiàn)熱點并 將熱點緩存訪問請求前置在應用層本地緩存的解決方案，這就是 TMC 產(chǎn)生的原因。
二、TMC 整體架構
TMC 整體架構如上圖，共分為三層：
存儲層：提供基礎的 kv 數(shù)據(jù)存儲能力，針對不同的業(yè)務場景選用不同的存儲服務（codis/zankv/aerospike）；
代理層：為應用層提供統(tǒng)一的緩存使用入口及通信協(xié)議，承擔分布式數(shù)據(jù)水平切分后的路由功能轉發(fā)工作；
應用層：提供統(tǒng)一客戶端給應用服務使用，內(nèi)置“熱點探測”、“本地緩存”等功能，對業(yè)務透明；
本篇聚焦在應用層客戶端的“熱點探測”、“本地緩存”功能。
TMC 本地緩存
如何透明
TMC 是如何減少對業(yè)務應用系統(tǒng)的入侵，做到透明接入的？
對于公司 Java 應用服務，在緩存客戶端使用方式上分為兩類：
- 基于 spring.data.redis包，使用 RedisTemplate編寫業(yè)務代碼；
- 基于 youzan.framework.redis包，使用 RedisClient編寫業(yè)務代碼；
不論使用以上那種方式，最終通過 JedisPool 創(chuàng)建的 Jedis 對象與緩存服務端代理層做請求交互。
TMC 對原生 jedis 包的 JedisPool 和 Jedis 類做了改造，在 JedisPool 初始化過程中集成 TMC“熱點發(fā)現(xiàn)”+“本地緩存”功能 Hermes-SDK包的初始化邏輯，使 Jedis客戶端與緩存服務端代理層交互時先與 Hermes-SDK交互，從而完成 “熱點探測”+“本地緩存”功能的透明接入。
對于 Java 應用服務，只需使用特定版本的 jedis-jar 包，無需修改代碼，即可接入 TMC 使用“熱點發(fā)現(xiàn)”+“本地緩存”功能，做到了對應用系統(tǒng)的最小入侵。
整體結構
模塊劃分
TMC 本地緩存整體結構分為如下模塊：
- Jedis-Client：Java 應用與緩存服務端交互的直接入口，接口定義與原生 Jedis-Client 無異。
- Hermes-SDK：自研“熱點發(fā)現(xiàn)+本地緩存”功能的 SDK 封裝，Jedis-Client 通過與它交互來集成相應能力。
- Hermes 服務端集群：接收 Hermes-SDK 上報的緩存訪問數(shù)據(jù)，進行熱點探測，將熱點 key 推送給 Hermes-SDK 做本地緩存。
- 緩存集群：由代理層和存儲層組成，為應用客戶端提供統(tǒng)一的分布式緩存服務入口。
- 基礎組件：etcd 集群、Apollo 配置中心，為 TMC 提供“集群推送”和“統(tǒng)一配置”能力。
基本流程
1）key 值獲?。?/p>
- Java 應用調(diào)用 Jedis-Client 接口獲取 key 的緩存值時，Jedis-Client 會詢問 Hermes-SDK 該 key 當前是否是 熱點key；
- 對于 熱點key ，直接從 Hermes-SDK 的 熱點模塊 獲取熱點 key 在本地緩存的 value 值，不去訪問 緩存集群 ，從而將訪問請求前置在應用層；
- 對于非 熱點key ，Hermes-SDK 會通過 Callable回調(diào) Jedis-Client 的原生接口，從 緩存集群 拿到 value 值；
- 對于 Jedis-Client 的每次 key 值訪問請求，Hermes-SDK 都會通過其 通信模塊 將 key 訪問事件 異步上報給 Hermes 服務端集群 ，以便其根據(jù)上報數(shù)據(jù)進行“熱點探測”；
2）key 值過期：
- Java 應用調(diào)用 Jedis-Client 的 set() del() expire()接口時會導致對應 key 值失效，Jedis-Client 會同步調(diào)用 Hermes-SDK 的 invalid()方法告知其“key 值失效”事件；
- 對于 熱點 key ，Hermes-SDK 的 熱點模塊 會先將 key 在本地緩存的 value 值失效，以達到本地數(shù)據(jù)強一致。同時 通信模塊 會異步將“key 值失效”事件通過 etcd 集群 推送給 Java 應用集群中其他 Hermes-SDK 節(jié)點；
- 其他 Hermes-SDK 節(jié)點的 通信模塊 收到 “key 值失效”事件后，會調(diào)用 熱點模塊 將 key 在本地緩存的 value 值失效，以達到集群數(shù)據(jù)最終一致；
3）熱點發(fā)現(xiàn)：
- Hermes 服務端集群 不斷收集 Hermes-SDK上報的 key 訪問事件，對不同業(yè)務應用集群的緩存訪問數(shù)據(jù)進行周期性（3s 一次）分析計算，以探測業(yè)務應用集群中的熱點 key列表；
- 對于探測到的熱點 key列表，Hermes 服務端集群 將其通過 etcd 集群 推送給不同業(yè)務應用集群的 Hermes-SDK 通信模塊，通知其對熱點 key列表進行本地緩存；
4）配置讀?。?/p>
- Hermes-SDK 在啟動及運行過程中，會從 Apollo 配置中心 讀取其關心的配置信息（如：啟動關閉配置、黑白名單配置、etcd 地址...）；
- Hermes 服務端集群 在啟動及運行過程中，會從 Apollo 配置中心 讀取其關心的配置信息（如：業(yè)務應用列表、熱點閾值配置、etcd 地址...）；
穩(wěn)定性
TMC 本地緩存穩(wěn)定性表現(xiàn)在以下方面：
- 數(shù)據(jù)上報異步化：Hermes-SDK 使用 rsyslog技術對“key 訪問事件”進行異步化上報，不會阻塞業(yè)務；
- 通信模塊線程隔離：Hermes-SDK 的 通信模塊 使用獨立線程池+有界隊列，保證事件上報&監(jiān)聽的 I/O 操作與業(yè)務執(zhí)行線程隔離，即使出現(xiàn)非預期性異常也不會影響基本業(yè)務功能；
- 緩存管控：Hermes-SDK 的 熱點模塊 對本地緩存大小上限進行了管控，使其占用內(nèi)存不超過 64MB（LRU），杜絕 JVM 堆內(nèi)存溢出的可能；
一致性
TMC 本地緩存一致性表現(xiàn)在以下方面：
- Hermes-SDK 的熱點模塊 僅緩存熱點 key 數(shù)據(jù)，絕大多數(shù)非熱點 key數(shù)據(jù)由緩存集群存儲；
- 熱點 key 變更導致 value 失效時，Hermes-SDK 同步失效本地緩存，保證 本地強一致；
- 熱點 key 變更導致 value 失效時，Hermes-SDK 通過 etcd 集群 廣播事件，異步失效業(yè)務應用集群中其他節(jié)點的本地緩存，保證 集群最終一致；
TMC 熱點發(fā)現(xiàn)
整體流程
TMC 熱點發(fā)現(xiàn)流程分為四步：
- 數(shù)據(jù)收集：收集 Hermes-SDK 上報的 key 訪問事件；
- 熱度滑窗：對 App 的每個 Key，維護一個時間輪，記錄基于當前時刻滑窗的訪問熱度；
- 熱度匯聚：對 App 的所有 Key，以 <key,熱度>的形式進行 熱度排序匯總；
- 熱點探測：對 App，從 熱 Key 排序匯總 結果中選出 TopN 的熱點 Key ，推送給 Hermes-SDK；
數(shù)據(jù)收集
Hermes-SDK 通過本地 rsyslog將 key 訪問事件 以協(xié)議格式放入 kafka ，Hermes 服務端集群 的每個節(jié)點消費 kafka 消息，實時獲取 key 訪問事件。
訪問事件協(xié)議格式如下：
- appName：集群節(jié)點所屬業(yè)務應用
- uniqueKey：業(yè)務應用 key 訪問事件的 key
- sendTime：業(yè)務應用 key 訪問事件的發(fā)生時間
- weight：業(yè)務應用 key 訪問事件的訪問權值
Hermes 服務端集群 節(jié)點將收集到的 key 訪問事件 存儲在本地內(nèi)存中，內(nèi)存數(shù)據(jù)結構為 Map<String,Map<String,LongAdder>>，對應業(yè)務含義映射為 Map<appName,Map<uniqueKey,熱度>>。
熱度滑窗
時間滑窗
Hermes 服務端集群 節(jié)點，對每個 App 的每個 key，維護了一個 時間輪：
- 時間輪中共 10 個 時間片，每個時間片記錄當前 key 對應 3 秒時間周期的總訪問次數(shù)；
- 時間輪 10 個時間片的記錄累加即表示當前 key 從當前時間向前 30 秒時間窗口內(nèi)的總訪問次數(shù)；
映射任務
Hermes 服務端集群 節(jié)點，對每個 App 每 3 秒 生成一個 映射任務 ，交由節(jié)點內(nèi) “緩存映射線程池” 執(zhí)行。映射任務 內(nèi)容如下：
- 對當前 App，從
Map<appName,Map<uniqueKey,熱度>>中取出 appName 對應的 Map，即Map<uniqueKey,熱度>>。 - 遍歷
Map<uniqueKey,熱度>>中的 key，對每個 key 取出其熱度存入其 時間輪對應的時間片中；
熱度匯聚
完成第二步“熱度滑窗”后，映射任務繼續(xù)對當前 App 進行“熱度匯聚”工作：
- 遍歷 App 的 key，將每個 key 的時間輪熱度進行匯總（即 30 秒時間窗口內(nèi)總熱度）得到探測時刻滑窗總熱度；
- 將 <key,滑窗總熱度> 以排序集合的方式存入 Redis 存儲服務中，即 熱度匯聚結果；
熱點探測
- 在前幾步，每 3 秒 一次的映射任務執(zhí)行，對每個 App 都會產(chǎn)生一份當前時刻的熱度匯聚結果 ；
- Hermes 服務端集群中的“熱點探測”節(jié)點，對每個 App，只需周期性從其最近一份熱度匯聚結果中取出達到熱度閾值的 TopN 的 key 列表，即可得到本次探測的熱點 key 列表；
TMC 熱點發(fā)現(xiàn)整體流程如下圖：
特性總結
實時性
Hermes-SDK 基于 rsyslog + kafka 實時上報 key 訪問事件。映射任務 3 秒一個周期完成“熱度滑窗” + “熱度匯聚”工作，當有 熱點訪問場景 出現(xiàn)時最長 3 秒即可探測出對應 熱點 key。
準確性
key 的熱度匯聚結果由“基于時間輪實現(xiàn)的滑動窗口”匯聚得到，相對準確地反應當前及最近正在發(fā)生訪問分布。
擴展性
Hermes 服務端集群節(jié)點無狀態(tài)，節(jié)點數(shù)可基于 kafka 的 partition 數(shù)量橫向擴展。
“熱度滑窗” + “熱度匯聚” 過程基于 App 數(shù)量，在單節(jié)點內(nèi)多線程擴展。
TMC 實戰(zhàn)效果
快手商家某次商品營銷活動
有贊商家通過快手直播平臺為某商品搞活動，造成該商品短時間內(nèi)被集中訪問產(chǎn)生訪問熱點，活動期間 TMC 記錄的實際熱點訪問效果數(shù)據(jù)如下：
某核心應用的緩存請求&命中率曲線圖：
- 上圖藍線為應用集群調(diào)用get()方法訪問緩存次數(shù)
- 上圖綠線為獲取緩存操作命中TMC本地緩存的次數(shù)
- 上圖為本地緩存命中率曲線圖
可以看出活動期間緩存請求量及本地緩存命中量均有明顯增長，本地緩存命中率達到近 80%（即應用集群中 80% 的緩存查詢請求被 TMC 本地緩存攔截）。
熱點緩存對應用訪問的加速效果
- 上圖為應用接口 QPS 曲線
- 上圖為應用接口 RT 曲線
可以看出活動期間應用接口的請求量有明顯增長，由于 TMC 本地緩存的效果應用接口的 RT 反而出現(xiàn)下降。
雙十一期間部分應用 TMC 效果展示
商品域核心應用效果
活動域核心應用效果
TMC 功能展望
在有贊，TMC 目前已為商品中心、物流中心、庫存中心、營銷活動、用戶中心、網(wǎng)關&消息等多個核心應用模塊提供服務，后續(xù)應用也在陸續(xù)接入中。
TMC 在提供“熱點探測” + “本地緩存”的核心能力同時，也為應用服務提供了靈活的配置選擇，應用服務可以結合實際業(yè)務情況在“熱點閾值”、“熱點 key 探測數(shù)量”、“熱點黑白名單”維度進行自由配置以達到更好的使用效果。
最后說一句
有贊技術團隊的博客，還有很多其他的優(yōu)秀文章，推薦給大家，自己去探索：
https://tech.youzan.com/
另外，雖然有贊的 TMC 多級緩存對于大家有著很大的啟發(fā)作用，思路是有了，但是畢竟沒有開源。
再給大家說一個京東開源的熱點 key 項目：
https://gitee.com/jd-platform-opensource/hotkey
京東這個項目的性能指標還是非常強悍的：
- 探測性能：8核單機worker端每秒可接收處理16萬個key探測任務，16核單機至少每秒平穩(wěn)處理30萬以上，實際壓測達到37萬，CPU平穩(wěn)支撐，框架無異常。
- 推送性能：在高并發(fā)寫入的同時，對外推送目前性能約平穩(wěn)推送每秒10-12萬次，譬如有1千臺server，一臺worker上每秒產(chǎn)生了100個熱key，那么這1秒會平穩(wěn)推送100 * 1000 = 10萬次，10萬次推送會明確在1s內(nèi)全部送達。如果是寫入少，推送多，以純推送來計數(shù)的話，該框架每秒可穩(wěn)定對外推送40-60萬次平穩(wěn)，80萬次極限可撐幾秒。
- 每秒單機吞吐量（寫入+對外推送）目前在70萬左右穩(wěn)定。
有興趣的可以去看看，技多不壓身。
推薦???：面試官:Java如何綁定線程到指定CPU上執(zhí)行?
我是 why，一個主要寫代碼，經(jīng)常寫文章，偶爾拍視頻的程序猿。
歡迎關注我呀。
等等，別走，我還有最后一句話：點贊、在看、分享、謝謝、愛你。