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

2021-10-14 05:57:13 字數 3591 閱讀 3030

「這個商品不錯,大家來看啊「,每個平台都有會有些大賣的商品,簡稱為爆品。這些商品會有個特點,就是訪問量特別大。我們專業上面可以稱之為熱點資料,在處理這些熱點商品時,系統需要做一些特殊的處理

針對熱點商品這些型別的資料,要考慮到訪問量比較大,大家首先想到的是快取,上redis快取,這點肯定沒有錯。系統框架如下:

上圖中,先從快取中獲取,沒有再到db獲取,並儲存到快取中。但有個問題會產生,熱點資料的訪問會比較大,如果快取一旦失效,所有請求同一時刻,會打到db上面,db肯定會崩潰。那怎麼辦呢?

快取一旦失效,如何重新構建快取?首先需要避免失效那一刻大量請求同時去重新構建快取。因為重新構建快取,需要到資料庫db中獲取資料,那乙個時刻的所有請求到db上面。方案有兩種,第乙個方案是把請求進入佇列中(這個老顧以後會介紹,關於庫存一致性的問題中,有涉及到這個知識點)。還有乙個方案就比較簡單,利用分布式鎖,只允許乙個請求執行緒去訪問db,其他請求阻塞,這樣就避免了很多請求打到db上。

具體怎麼實現可以看老顧之前的文章【如何利用鎖,防止快取擊穿?重構思想的重要性
這個方案就是利用redis本身的特性,導致的問題是因為快取失效了,那我們可以讓快取永不過期就行了。這個方案中需要考慮兩個情況:

1、熱點商品上線前需要預熱,也就是在商品正式發布到前端時,需要提前把商品資訊進行快取,避免跟快取失效的情況一樣。 2、更新商品資訊機制,如何在商品資訊更新後,及時更新快取中的商品資訊。這個也比較簡單在更新商品事件中,增加個更新訊息,由快取服務進行消費,更新快取資訊。
上面兩個方案是網上經常提到的方案,其實這兩個方案會存在乙個問題,也就是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帶上,這樣就是知道是哪些商品了
到此為止,老顧就把熱點資料的問題、解決方案以及熱點發現介紹完了,希望能夠幫助小夥伴。當然整個解決方案的搭建,還需要小夥伴結合自身業務去實現。

如果小夥伴們部署到阿里雲上面,阿里雲上面也有類似方案
謝謝大家閱讀!!!

擴充套件:如何處理redis集群中的hot key

你所不知道的 const

const 常量是不可修改的,也就是說only read,例如 const int nbuffsize 512 nbuffsize 0 error就是因為const 常量不能修改,所以定義時必須初始化預設在全域性作用域中定義的非const變數可以在整個程式中訪問,例如 int ncounter ex...

你所不知道的background

今天要說說css中background這個屬性裡面的大學問。在乙個宣告中設定所有的背景屬性 body 看到這串 你怕了嗎?知道他們都代表啥意思嘛?不要捉急,來看展開式。展開式 background color設定元素的背景顏色,不能設定到外邊距,可以繼承父級的背景顏色,預設為透明。backgroun...

overflow hidden 你所不知道的事

overflow hidden 你所不知道的事 overflow hidden這個css樣式是大家常用到的css樣式,但是大多數人對這個樣式的理解僅僅侷限於隱藏溢位,而對於清除浮動這個含義不是很了解。這是乙個常用的div寫法,下面我們來書寫樣式。大家可以在dmx中自己做試驗 wai nei 可以看到...