69_緩存預熱解決方案：基於storm實時熱點統計的分佈式並行緩存預熱

一、緩存預熱

緩存冷啓動，redis啓動後，一點數據都沒有，直接就對外提供服務了，mysql就裸奔

（1）提早給redis中灌入部分數據，再提供服務
（2）確定不可能將全部數據都寫入redis，由於數據量太大了，第一耗費的時間太長了，第二根本redis容納不下全部的數據
（3）須要根據當天的具體訪問狀況，實時統計出訪問頻率較高的熱數據
（4）而後將訪問頻率較高的熱數據寫入redis中，確定是熱數據也比較多，咱們也得多個服務並行讀取數據去寫，並行的分佈式的緩存預熱
（5）而後將灌入了熱數據的redis對外提供服務，這樣就不至於冷啓動，直接讓數據庫裸奔了

二、nginx+lua將訪問流量上報到kafka中

要統計出來當前最新的實時的熱數據是哪些，咱們就得將商品詳情頁訪問的請求對應的流量，日誌，實時上報到kafka中

三、storm從kafka中消費數據，實時統計出每一個商品的訪問次數，訪問次數基於LRU內存數據結構的存儲方案

優先用內存中的一個LRUMap去存放，性能高，並且沒有外部依賴

我以前作過的一些項目，不光是這個項目，還有不少其餘的，一些廣告計費類的系統，storm

不然的話，依賴redis，咱們就是要防止redis掛掉數據丟失的狀況，就不合適了; 用mysql，扛不住高併發讀寫; 用hbase，hadoop生態系統，維護麻煩，過重了

其實咱們只要統計出最近一段時間訪問最頻繁的商品，而後對它們進行訪問計數，同時維護出一個前N個訪問最多的商品list便可

熱數據，最近一段時間，能夠拿到最近一段，好比最近1個小時，最近5分鐘，1萬個商品請求，統計出最近這段時間內每一個商品的訪問次數，排序，作出一個排名前N的list

計算好每一個task大體要存放的商品訪問次數的數量，計算出大小

而後構建一個LRUMap，apache commons collections有開源的實現，設定好map的最大大小，就會自動根據LRU算法去剔除多餘的數據，保證內存使用限制

即便有部分數據被幹掉了，而後下次來從新開始計數，也不要緊，由於若是它被LRU算法幹掉，那麼它就不是熱數據，說明最近一段時間都不多訪問了

四、每一個storm task啓動的時候，基於zk分佈式鎖，將本身的id寫入zk同一個節點中

五、每一個storm task負責完成本身這裏的熱數據的統計，每隔一段時間，就遍歷一下這個map，而後維護一個前3個商品的list，更新這個list

六、寫一個後臺線程，每隔一段時間，好比1分鐘，都將排名前3的熱數據list，同步到zk中去，存儲到這個storm task對應的一個znode中去

七、咱們須要一個服務，好比說，代碼能夠跟緩存數據生產服務放一塊兒，可是也能夠放單獨的服務

服務可能部署了不少個實例

每次服務啓動的時候，就會去拿到一個storm task的列表，而後根據taskid，一個一個的去嘗試獲取taskid對應的znode的zk分佈式鎖

若是能獲取到分佈式鎖的話，那麼就將那個storm task對應的熱數據的list取出來

而後將數據從mysql中查詢出來，寫入緩存中，進行緩存的預熱，多個服務實例，分佈式的並行的去作，基於zk分佈式鎖作了協調了，分佈式並行緩存的預熱