秒殺筆記二八原則

發現「熱點」

處理「熱點」

有針對性的處理好系統的「熱點資料」，結合「二八原則」舉例說明秒殺場景的處理思想。

電商平台，經常被訪問的商品統稱為「熱點商品」;

這些商品在很短的時間內被大量使用者執行訪問、新增購物車、下單等操作，這些操作成為熱點操作;

熱點分為「熱點操作」和「熱點資料」

標題描述

靜態熱點資料

能夠提前**是熱點資料

1. 賣家報名方式提前篩選，通過報名系統提前標記。

2. 通過一段時間的運營資料(購物車記錄、成交記錄、下單記錄等)基於大資料分析系統分析出可能成為熱點的資料。

動態熱點資料

不能被提前**的資料

例如：買家在某流量較大的平台做了廣告，突然訪問劇增，此商品成為了熱點商品。

因為我們主要講的是「秒殺」場景，我們可以認為「參加秒殺的商品就是秒殺商品」，這固然正確，但是我們如何來確認這些商品就是熱點資料呢。

1. 賣家報名參加方式提交把熱點商品獲取，通過後台管理端對這些商品處理，例如新增快取（redis）。

2. 也可以通過每天商品訪問記錄，獲取top n product，這些top n product我們可以認為是熱門資料。

缺點：實時性較差。

動態熱點發現系統具體實現

如下圖所示：使用者請求商品，雖然經過了很多路徑，但是我們主要依賴前面的導購頁（包括首頁、搜尋頁面、商品詳情、購物車等）提前識別哪些商品訪問高，通過這些系統中的中介軟體收集熱點資料，並記錄日誌。

通過上游沒台機器配置的agent把日誌彙總到聚合和分析集群中，把符合一定規則的熱點，通過訂閱分發系統再推送到對應到系統。可以把熱點資料填充到cache中，或者直接推送到應用伺服器的記憶體中，還可以對這些資料進行攔截，下游系統可以訂閱這些資料，然後根據需求處理這裡資料

打造熱點發現系統的注意事項：

熱點處理思路分為：優化、限制、隔離

優化熱點資料，最有效的就是快取熱點資料，如果熱點資料做了動靜分離，那麼可以長期快取靜態資料。但是，快取熱點資料更多的是「臨時」快取，用乙個佇列短暫快取數秒鐘，由於佇列長度有限，可採用lru淘汰演算法替換。

限制更多的是一種保護機制，限制的方式有很多，例如對訪問對商品id做一致性hash，然後根據hash做分桶，每個分桶設定乙個處理佇列，這樣可以把熱點商品限制在乙個請求佇列裡，防止因某些熱點商品占用太多伺服器資源，避免其他請求沒有資源可用。

秒殺系統設計第一原則即是將這種熱點資料隔離出來，不讓1%請求影響另外99%請求。隔離後更方便對1%請求做針對性優化。

具體「秒殺」業務，可以在以下幾個層次實現隔離：

令牌桶實現方式（待完善）

gateway實現請求攔截，並儲存到mongodb，作為熱點分析資料（待完善）

nginx redis呼叫（待完善）

秒殺筆記 二八原則