您好,登錄后才能下訂單哦!
這篇文章主要介紹了Redis find hot key的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
Before
緩存雪崩,即緩存同一時間大面積的失效,這個時候又來了一波請求,結果請求都懟到數據庫上,從而導致數據庫連接異常。
解決方案:
(一)給緩存的失效時間,加上一個隨機值,避免集體失效。
(二)使用互斥鎖,但是該方案吞吐量明顯下降了。
(三)雙緩存。我們有兩個緩存,緩存A和緩存B。緩存A的失效時間為20分鐘,緩存B不設失效時間。自己做緩存預熱操作。然后細分以下幾個小點
I 從緩存A讀數據庫,有則直接返回
II A沒有數據,直接從B讀數據,直接返回,并且異步啟動一個更新線程。
III 更新線程同時更新緩存A和緩存B。
after
對任意突發性的無法預先感知的熱點數據,包括并不限于熱點數據(如突發大量請求同一個商品)、熱用戶(如惡意爬蟲刷子)、熱接口(突發海量請求同一個接口)等,進行毫秒級精準探測到。然后對這些熱數據、熱用戶等,推送到所有服務端JVM內存中,以大幅減輕對后端數據存儲層的沖擊,并可以由使用者決定如何分配、使用這些熱key(譬如對熱商品做本地緩存、對熱用戶進行拒絕訪問、對熱接口進行熔斷或返回默認值)。這些熱數據在整個服務端集群內保持一致性,并且業務隔離,worker端性能強悍。
該框架歷經多次壓測,8核單機worker端每秒可接收處理16萬個key探測任務,16核單機至少每秒平穩處理30萬以上,實際壓測達到37萬,CPU平穩支撐,框架無異常。
建議搭配公眾號內容食用京東毫秒級熱key探測框架設計與實踐,已實戰于618大促
核心功能:熱數據探測并推送至集群各個服務器
適用場景:
1 mysql熱數據本地緩存
2 redis熱數據本地緩存
3 黑名單用戶本地緩存
4 爬蟲用戶限流
5 接口、用戶維度限流
6 單機接口、用戶維度限流限流
7 集群用戶維度限流
8 集群接口維度限流
該開源項目戰略意義重大,經歷百萬級并發,參與京東開源中間件項目建設,一直在等你。
gitee源碼地址https://gitee.com/jd-platform-opensource/hotkey
另推薦閱讀解決任意的多線程并行、串行、阻塞、依賴、回調的并行框架,可以任意組合各線程的執行順序,帶全鏈路執行結果回調。多線程編排一站式解決方案
gitee地址:https://gitee.com/jd-platform-opensource/asyncTool?_from=gitee_search
感謝你能夠認真閱讀完這篇文章,希望小編分享的“Redis find hot key的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。