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