發現動態熱點數據
我們可以通過賣家報名或者大數據預測這些手段來提前預測靜態熱點數據，但這其中有一個痛點，就是實時性較差，如果我們的系統能在秒級內自動發現熱點商品那就完美了。
能夠動態地實時發現熱點不僅對秒殺商品，對其他熱賣商品也同樣有價值，所以我們需要想辦法實現熱點的動態發現功能。
這裏我給出一個動態熱點發現系統的具體實現。
構建一個異步的系統，它可以收集交易鏈路上各個環節中的中間件產品的熱點 Key，如 Nginx、緩存、RPC 服務框架等這些中間件（一些中間件產品本身已經有熱點統計模塊）。
建立一個熱點上報和可以按照需求訂閱的熱點服務的下發規範，主要目的是通過交易鏈路上各個系統（包括詳情、購物車、交易、優惠、庫存、物流等）訪問的時間差，把上游已經發現的熱點透傳給下游系統，提前做好保護。比如，對於大促高峯期，詳情繫統是最早知道的，在統一接入層上 Nginx 模塊統計的熱點 URL。
將上游系統收集的熱點數據發送到熱點服務檯，然後下游系統（如交易系統）就會知道哪些商品會被頻繁調用，然後做熱點保護
這裏我給出了一個圖，其中用戶訪問商品時經過的路徑有很多，我們主要是依賴前面的導購頁面（包括首頁、搜索頁面、商品詳情、購物車等）提前識別哪些商品的訪問量高，通過這些系統中的中間件來收集熱點數據，並記錄到日誌中
我們通過部署在每臺機器上的 Agent 把日誌彙總到聚合和分析集羣中，然後把符合一定規則的熱點數據，通過訂閱分發系統再推送到相應的系統中。你可以是把熱點數據填充到 Cache 中，或者直接推送到應用服務器的內存中，還可以對這些數據進行攔截，總之下游系統可以訂閱這些數據，然後根據自己的需求決定如何處理這些數據。
打造熱點發現系統時，我根據以往經驗總結了幾點注意事項。
這個熱點服務後臺抓取熱點數據日誌最好採用異步方式，因爲“異步”一方面便於保證通用性，另一方面又不影響業務系統和中間件產品的主流程。
熱點服務發現和中間件自身的熱點保護模塊並存，每個中間件和應用還需要保護自己。熱點服務檯提供熱點數據的收集和訂閱服務，便於把各個系統的熱點數據透明出來
熱點發現要做到接近實時（3s 內完成熱點數據的發現），因爲只有做到接近實時，動態發現纔有意義，才能實時地對下游系統提供保護。