Redis find hot key的示例分析

這篇文章主要介紹了Redis find hot key的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

Before

緩存雪崩，即緩存同一時間大面積的失效，這個時候又來了一波請求，結果請求都懟到數(shù)據(jù)庫上，從而導致數(shù)據(jù)庫連接異常。

解決方案:

(一)給緩存的失效時間，加上一個隨機值，避免集體失效。

(二)使用互斥鎖，但是該方案吞吐量明顯下降了。

(三)雙緩存。我們有兩個緩存，緩存A和緩存B。緩存A的失效時間為20分鐘，緩存B不設失效時間。自己做緩存預熱操作。然后細分以下幾個小點

I 從緩存A讀數(shù)據(jù)庫，有則直接返回

II A沒有數(shù)據(jù)，直接從B讀數(shù)據(jù)，直接返回，并且異步啟動一個更新線程。

III 更新線程同時更新緩存A和緩存B。

after

對任意突發(fā)性的無法預先感知的熱點數(shù)據(jù)，包括并不限于熱點數(shù)據(jù)（如突發(fā)大量請求同一個商品）、熱用戶（如惡意爬蟲刷子）、熱接口（突發(fā)海量請求同一個接口）等，進行毫秒級精準探測到。然后對這些熱數(shù)據(jù)、熱用戶等，推送到所有服務端JVM內存中，以大幅減輕對后端數(shù)據(jù)存儲層的沖擊，并可以由使用者決定如何分配、使用這些熱key（譬如對熱商品做本地緩存、對熱用戶進行拒絕訪問、對熱接口進行熔斷或返回默認值）。這些熱數(shù)據(jù)在整個服務端集群內保持一致性，并且業(yè)務隔離，worker端性能強悍。

該框架歷經(jīng)多次壓測，8核單機worker端每秒可接收處理16萬個key探測任務，16核單機至少每秒平穩(wěn)處理30萬以上，實際壓測達到37萬，CPU平穩(wěn)支撐，框架無異常。

建議搭配公眾號內容食用京東毫秒級熱key探測框架設計與實踐，已實戰(zhàn)于618大促

核心功能：熱數(shù)據(jù)探測并推送至集群各個服務器

適用場景：

1 mysql熱數(shù)據(jù)本地緩存

2 redis熱數(shù)據(jù)本地緩存

3 黑名單用戶本地緩存

4 爬蟲用戶限流

5 接口、用戶維度限流

6 單機接口、用戶維度限流限流

7 集群用戶維度限流

8 集群接口維度限流

該開源項目戰(zhàn)略意義重大，經(jīng)歷百萬級并發(fā)，參與京東開源中間件項目建設，一直在等你。

gitee源碼地址https://gitee.com/jd-platform-opensource/hotkey

另推薦閱讀解決任意的多線程并行、串行、阻塞、依賴、回調的并行框架，可以任意組合各線程的執(zhí)行順序，帶全鏈路執(zhí)行結果回調。多線程編排一站式解決方案

gitee地址：https://gitee.com/jd-platform-opensource/asyncTool?_from=gitee_search

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Redis find hot key的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!