啥是热数据探测？
如果數據也要像垃圾一樣分類，熱數據算哪類呢？
大家好，我是魚皮，今天分享一個有點兒干的技術知識。
大家知道，各種網站、應用的運行離不開數據的支撐，尤其對于企業來說，業務數據就是它的生命。
但有時，將所有數據堆成一坨、統一處理可能無法滿足我們對性能和存儲空間等要求。因此，我們需要對數據進行分類處理，以適應不同的業務需求和應用場景。
其中，有一種劃分方式是將數據分為 “熱數據”、“冷數據”，甚至還有 “暖數據”！
就和垃圾分類一樣一樣的~
先來聊一聊什么是熱數據吧！
什么是熱數據？
顧名思義，熱數據是指 很熱門、頻繁被訪問 的數據。
比如某度熱榜上的新聞，可能每秒都會有成千上萬次的訪問量。
根據熱數據的特點，又可以分為兩類：
-
有預期：數據成為熱門是在意料之中的，比如提前預告的大促活動中由網紅代言的爆款商品，某寶的雙十一購物節就是最好的例子。
-
無預期：數據的訪問量突然飆升！可能是受到了人為惡意攻擊、網絡爬蟲，或者是不經意間突然火爆的內容。比如突然出現了一個大新聞，某浪微博還沒來得及做好防護，可能就炸了。
為了應對熱數據，通常我們會選用緩存技術，將數據以 K / V（鍵值對）的方式提前存儲到內存中。
當我們需要訪問緩存數據時，需要根據一個 key 字符串，來找到對應的值。
頻繁被訪問的 key，又稱為熱 key，熱 key 是一個廣泛的概念，不僅僅局限于緩存系統，例如以下這些都是熱 key：
了解了啥是熱數據后，我們再來聊聊熱數據探測技術，即 “找出熱數據” 的技術。
為什么要檢測熱數據？
我們檢測熱數據的原因很簡單：
1. 提升性能
如果使用分布式緩存，在讀取時還是需要網絡通訊的，就會有額外的時間開銷。那如果能對熱點數據提前進行本地緩存，即預熱，就能大幅提升機器讀取數據的性能，減輕下層緩存集群的壓力。
當然，這不意味著所有數據都應該存儲到本地。緩存級數越多，更新操作就越復雜，數據不一致的風險就越大！
2. 規避風險
對于無預期的熱數據（熱 key），可能會對業務帶來極大的風險，可將風險分為兩個層次：
對數據層的風險
正常情況下，Redis 緩存單機就可支持十萬左右 QPS（每秒請求量），并能通過集群增大并發度。對于并發量一般的系統，用 Redis 做緩存就足夠了。但是如果有一個商品數據突然爆火，或者收到惡意請求，對該數據 key 的訪問 QPS 可能飆升到百萬、千萬量級！在低版本 Redis 單線程的工作方式下，會導致正常的請求排隊，無法及時響應，嚴重時會導致整個分片集群癱瘓。
還有一種情況，某熱點 key 突然過期，會導致大量請求直接砸向脆弱的數據庫，導致數據庫掛掉！
對應用服務的風險
每個應用在單位時間所能接受和處理的請求量是有限的，如果受到惡意請求的攻擊，讓惡意用戶獨自占用了大量請求處理資源，就會導致其他人畜無害的正常用戶的請求無法及時響應。
因此，需要一套動態熱 key 檢測機制，當無預期的熱點數據出現時，第一時間發現他，并針對這些數據進行特殊處理。如本地緩存、拒絕惡意用戶、接口限流 / 降級等。在提升數據訪問性能的同時規避可能的風險。
那么如何檢測熱數據呢？
如何檢測熱數據？
首先，我們需要給 “熱” 定義一個閾值或規則，到底多熱算熱呢？
可以根據經驗值定義，也可以根據系統數據的平均熱度來定義，比如 1 秒內訪問 1000 次的數據算是熱數據。
對于單機應用，檢測熱數據很簡單，直接在本地為每個key創建一個滑動窗口計數器，統計單位時間內的訪問總數（頻率），并通過一個集合存放檢測到的熱 key。
而對于分布式應用，對熱 key 的訪問是分散在不同的機器上的，無法在本地獨立地進行計算，因此，需要一個獨立的、集中的 熱 key 計算單元。
至此，可將熱數據探測工作分為配置規則、熱 key 上報、熱 key 統計、熱 key 推送四個步驟：
通過上述步驟，一套基本的熱 key 檢測機制就完成了。但熱數據探測系統往往會面對復雜的業務場景，還要考慮其他的問題，比如 key 失效處理等。
為滿足高并發場景，在設計熱 key 探測框架時，還應重點關注如下指標：
此外，優秀的熱 key 探測框架還應滿足易接入、業務無侵入、可動態配置、規則熱更新、可視化管理等特性。
最后，想深入學習的同學可以看一下京東開源的熱 key 探測框架 JD-hotkey 以及有贊開源的 TMC，他們的設計都非常巧妙。
我之前也寫過有關這兩個框架的分析文章，后面有機會整理下再發出來。
總結
- 上一篇： 面试分享：那些年我经历过的一些面试，以及
- 下一篇： xp的boot.ini文件内容