小知識，啥是熱數據探測？

如果數據也要像垃圾一樣分類，熱數據算哪類呢？

大家知道，各種網站、應用的運行離不開數據的支撐，尤其對於企業來說，業務數據就是它的生命。

但有時，將所有數據堆成一坨、統一處理可能無法滿足我們對性能和存儲空間等要求。因此，我們需要對數據進行分類處理，以適應不同的業務需求和應用場景。

其中，有一種劃分方式是將數據分爲 “熱數據”、“冷數據”，甚至還有 “暖數據”！

就和垃圾分類一樣一樣的~

先來聊一聊什麼是熱數據吧！

什麼是熱數據？

顧名思義，熱數據是指 很熱門、頻繁被訪問 的數據。

比如某度熱榜上的新聞，可能每秒都會有成千上萬次的訪問量。

根據熱數據的特點，又可以分爲兩類：

• 有預期：數據成爲熱門是在意料之中的，比如提前預告的大促活動中由網紅代言的爆款商品，某寶的雙十一購物節就是最好的例子。

• 無預期：數據的訪問量突然飆升！可能是受到了人爲惡意攻擊、網絡爬蟲，或者是不經意間突然火爆的內容。比如突然出現了一個大新聞，某浪微博還沒來得及做好防護，可能就炸了。

爲了應對熱數據，通常我們會選用緩存技術，將數據以 K / V（鍵值對）的方式提前存儲到內存中。

鍵值對

當我們需要訪問緩存數據時，需要根據一個 key 字符串，來找到對應的值。

頻繁被訪問的 key，又稱爲熱 key，熱 key 是一個廣泛的概念，不僅僅侷限於緩存系統，例如以下這些都是熱 key：

1. 數據庫中被頻繁訪問的主鍵，如爆款應用的 appId

2. K / V 緩存系統中經常被訪問的 key

3. 惡意攻擊、機器人刷的請求信息，如用戶的 userId、機器 IP 等

4. 頻繁被訪問的接口地址，如 app 信息查詢 /app/query

5. 統計單個用戶訪問某接口的頻率，如 userId + /app/query

6. 統計某臺機器訪問某接口的頻率，如 IP + /app/query

7. 統計某用戶訪問某接口特定內容的頻率，如 userId + /app/query + appId

瞭解了啥是熱數據後，我們再來聊聊熱數據探測技術，即 “找出熱數據” 的技術。

爲什麼要檢測熱數據？

我們檢測熱數據的原因很簡單：

2.1 提升性能

如果使用分佈式緩存，在讀取時還是需要網絡通訊的，就會有額外的時間開銷。那如果能對熱點數據提前進行本地緩存，即預熱，就能大幅提升機器讀取數據的性能，減輕下層緩存集羣的壓力。

熱數據多級緩存讀取流程

當然，這不意味着所有數據都應該存儲到本地。緩存級數越多，更新操作就越複雜，數據不一致的風險就越大！

2.2 規避風險

對於無預期的熱數據（熱 key），可能會對業務帶來極大的風險，可將風險分爲兩個層次：

對數據層的風險

正常情況下，Redis 緩存單機就可支持十萬左右 QPS（每秒請求量），並能通過集羣增大併發度。對於併發量一般的系統，用 Redis 做緩存就足夠了。但是如果有一個商品數據突然爆火，或者收到惡意請求，對該數據 key 的訪問 QPS 可能飆升到百萬、千萬量級！在低版本 Redis 單線程的工作方式下，會導致正常的請求排隊，無法及時響應，嚴重時會導致整個分片集羣癱瘓。

還有一種情況，某熱點 key 突然過期，會導致大量請求直接砸向脆弱的數據庫，導致數據庫掛掉！

對應用服務的風險

每個應用在單位時間所能接受和處理的請求量是有限的，如果受到惡意請求的攻擊，讓惡意用戶獨自佔用了大量請求處理資源，就會導致其他人畜無害的正常用戶的請求無法及時響應。

惡意請求導致的請求排隊

因此，需要一套動態熱 key 檢測機制，當無預期的熱點數據出現時，第一時間發現他，並針對這些數據進行特殊處理。如本地緩存、拒絕惡意用戶、接口限流 / 降級等。在提升數據訪問性能的同時規避可能的風險。

那麼如何檢測熱數據呢？

如何檢測熱數據？

首先，我們需要給 “熱” 定義一個閾值或規則，到底多熱算熱呢？

可以根據經驗值定義，也可以根據系統數據的平均熱度來定義，比如 1 秒內訪問 1000 次的數據算是熱數據。

對於單機應用，檢測熱數據很簡單，直接在本地爲每個 key 創建一個滑動窗口計數器，統計單位時間內的訪問總數（頻率），並通過一個集合存放檢測到的熱 key。

滑動窗口

而對於分佈式應用，對熱 key 的訪問是分散在不同的機器上的，無法在本地獨立地進行計算，因此，需要一個獨立的、集中的 熱 key 計算單元。

至此，可將熱數據探測工作分爲配置規則、熱 key 上報、熱 key 統計、熱 key 推送四個步驟：

1. 配置規則：指定熱 key 的上報條件，圈出需要重點監測的 key

2. 熱 key 上報：每臺機器將自己的 key 訪問情況上報給集中計算單元

3. 熱 key 統計：收集各應用實例上報的信息，使用滑動窗口算法計算 key 的熱度

4. 熱 key 推送：當 key 的熱度達到設定值時，推送熱 key 信息至所有應用實例，各應用實例將 key 值進行本地緩存。

上報和計算

通過上述步驟，一套基本的熱 key 檢測機制就完成了。但熱數據探測系統往往會面對複雜的業務場景，還要考慮其他的問題，比如 key 失效處理等。

有贊 TMC 熱 Key 探測設計

爲滿足高併發場景，在設計熱 key 探測框架時，還應重點關注如下指標：

1. 實時性：考慮到熱 key 的突發性（甚至可能是 1 毫秒），必須能夠實時發現熱 key 並推送

2. 高性能：框架應保持輕量且高性能，有效降低成本

3. 準確性：精準探測符合規則的熱 key，不漏報、更不誤報

4. 一致性：保證應用實例與本地緩存的熱 key 一致，不能出現數據錯誤

5. 可擴展：要統計的 key 數量級很大時，集中計算集羣可水平擴展

此外，優秀的熱 key 探測框架還應滿足易接入、業務無侵入、可動態配置、規則熱更新、可視化管理等特性。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Ie56p2ADykB4jwBjJRlsAg