你所不知道的Redis熱點問題以及如何發現熱點

享學課堂特邀做者：老顧

前言

「這個商品不錯，你們來看啊「，每一個平臺都有會有些大賣的商品，簡稱爲爆品。這些商品會有個特色，就是訪問量特別大。咱們專業上面能夠稱之爲熱點數據，在處理這些熱點商品時，系統須要作一些特殊的處理。

緩存化

針對熱點商品這些類型的數據，要考慮到訪問量比較大，你們首先想到的是緩存，上redis緩存，這點確定沒有錯。系統框架以下： 

上圖中，先從緩存中獲取，沒有再到DB獲取，並保存到緩存中。但有個問題會產生，熱點數據的訪問會比較大，若是緩存一旦失效，全部請求同一時刻，會打到DB上面，DB確定會崩潰。那怎麼辦呢？

分佈式鎖

緩存一旦失效，如何從新構建緩存？首先須要避免失效那一刻大量請求同時去從新構建緩存。由於從新構建緩存，須要到數據庫DB中獲取數據，那一個時刻的全部請求到DB上面。方案有兩種，第一個方案是把請求進入隊列中（這個老顧之後會介紹，關於庫存一致性的問題中，有涉及到這個知識點）。還有一個方案就比較簡單，利用分佈式鎖，只容許一個請求線程去訪問DB，其餘請求阻塞，這樣就避免了不少請求打到DB上。

具體怎麼實現能夠看老顧以前的文章【如何利用鎖，防止緩存擊穿？重構思想的重要性】

永不過時

這個方案就是利用redis自己的特性，致使的問題是由於緩存失效了，那咱們可讓緩存永不過時就好了。這個方案中須要考慮兩個狀況：

一、熱點商品上線前須要預熱，也就是在商品正式發佈到前端時，須要提早把商品信息進行緩存，避免跟緩存失效的狀況同樣。 二、更新商品信息機制，如何在商品信息更新後，及時更新緩存中的商品信息。這個也比較簡單在更新商品事件中，增長個更新消息，由緩存服務進行消費，更新緩存信息。

遺留問題

上面兩個方案是網上常常提到的方案，其實這兩個方案會存在一個問題，也就是redis達到了負載極限怎麼辦？也就是熱點商品的訪問量，咱們的單臺redis扛不住了。

小夥伴們會有疑問，redis能夠上集羣啊，不就解決了嗎？

咱們先了解一下，redis cluster集羣部署方案

上圖是redis經典的三主三從集羣方案，客戶端進行set和get時，都是走的主redis，從redis只是個備份，主要做用是用來作高可用的，如：主redis掛了，從redis頂上。

備註：老顧這裏介紹的是redis集羣部署方案，若是是以前的redis主從方案，另外討論

從redis是不負責set和get請求的，即便請求打到從redis節點，從redis也會轉發給主redis。而其餘的主redis，是用來作數據擴容的。

即就是商品A的信息，只會存在一個主redis中，其餘主redis是沒有此商品A的信息的，這就是redis集羣哈希槽的特色。

也就是小夥伴剛纔想到的作redis集羣這個方案是不行的，由於熱點數據只會在一個主redis中。會存在單臺redis負載不足（達到網卡、網絡上限。達到這個瓶頸流量表明很是大了）。那怎麼辦呢？

讀寫分離

上面咱們提到從redis只不負責讀和寫請求的，但redis官方提供了一個方法，在操做讀請求時，能夠先加上readonly命令，這樣從redis就能夠提供讀請求服務了，不須要轉發到主redis。

根據這個特性，咱們能夠對客戶端工具進行改造，讀請求方法時，加上readonly這個命令，從而實現讀寫分離，提升了從redis的利用率。

即達到了多臺從redis去扛大量請求了，減小了主redis壓力。這個方案須要對客戶端進行改造，並且redis官方推薦沒有必要使用讀寫分離。

本地緩存

這個方案就是多級緩存的方案，把緩存前置，架構圖以下：

改造web應用服務，在獲取到redis緩存後，在web服務本地把熱點的數據進行緩存，由於熱點的商品不會不少，因此保存在本地緩存中，是沒有問題的。這樣請求數據時，若是web本地有緩存數據，就直接返回了。

這樣前端3個web應用就分擔了redis緩存的壓力，如訪問過大就能夠增長web應用服務，原本web應用服務就須要集羣化

熱點發現

本地緩存的方案中，有一個問題須要解決，那就是怎麼知道哪些數據是熱點數據？由於本地緩存資源有限，不可能把全部的商品數據進行緩存，它只會緩存熱點的數據。那怎麼知道數據是熱點數據呢？

人爲預測

就是人工標記，預測這個商品會成爲熱點，打個標記。web應用根據這個標記把此商品保存到本地緩存中

這個方案，是根據運營人員的經驗進行預測，太不靠譜了。

系統推算

這個方案是根據實實在在的數據訪問量進行推算造成，網上也介紹了用訪問日誌的什麼算法，推算哪些是熱點數據。 老顧這裏分享一個比較簡單的方式，就是利用redis4.x自身特性，LFU機制發現熱點數據。實現很簡單，只要把redis內存淘汰機制設置爲allkeys-lfu或者volatile-lfu方式，再執行

./redis-cli --hotkeys複製代碼

會返回訪問頻率高的key，並從高到底的排序

那就是咱們的熱點數據的key了。

備註：在設置key時，須要把商品id帶上，這樣就是知道是哪些商品了

總結

到此爲止，老顧就把熱點數據的問題、解決方案以及熱點發現介紹完了，但願可以幫助小夥伴。固然整個解決方案的搭建，還須要小夥伴結合自身業務去實現。

若是小夥伴們部署到阿里雲上面，阿里雲上面也有相似方案

謝謝你們閱讀！！！

END

歡迎長按下圖關注公衆號：享學課堂online！

公衆號後臺回覆【java】，獲取精選準備的架構學習資料（視頻+文檔+架構筆記）

學習分享：shimo.im/docs/vrfAWT…