「這個商品不錯,大家來看啊「,每個平台都有會有些大賣的商品,簡稱為爆品。這些商品會有個特點,就是訪問量特別大。我們專業上面可以稱之為熱點資料,在處理這些熱點商品時,系統需要做一些特殊的處理。
針對熱點商品這些型別的資料,要考慮到訪問量比較大,大家首先想到的是快取,上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熱點問題
請求分片集中,超過單 server 的效能極限。在服務端讀資料進行訪問時,往往會對資料進行分片切分,此過程中會在某一主機 server 上對相應的 key 進行訪問,當訪問超過 server 極限時,就會導致熱點 key 問題的產生。需要避免失效那一刻大量請求同時去重新構建快取。因為重新構建快取,需...
Hbase rowkey熱點問題
當處理由連續事件得到的資料時,即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是 rowkey 中含有事件發生時間。帶來的乙個問題便是 hbase 對於row 的不均衡分布,它們被儲存在乙個唯一的 rowkey 區間中,被稱為 region 區間的範圍被稱...
Hbase熱點問題
當處理由連續事件得到的資料時,即時間上連續的資料。這些資料可能來自於某個感測器網路 交易或者乙個監控系統。它們顯著的特點就是rowkey中含有事件發生時間。帶來的乙個問題便是hbase對於row的不均衡分布,它們被儲存在乙個唯一的rowkey區間中,被稱為region,區間的範圍被稱為start k...