秒殺系統架構設計-第三章

秒殺系統架構設計-第三章

二八原則：有針對性的處理好系統的"熱點數據"

一部分商品被搭理亮用戶訪問的熱賣商品，就是常說的"熱點商品"。

熱點商品種極端的例子就是秒殺商品，再很短期內被大量用戶執行訪問、添加購物車、下單等操做，這些操做咱們稱爲"熱點操做"。

咱們必定要關注熱點，由於熱點會對系統產生一系列的影響。首先，熱點請求會大量佔用服務器處理資源，熱點請求所在的比例下，卻可能佔用90%的服務器資源。

什麼是"熱點"

熱點分爲熱點操做和熱點數據。

所謂"熱點操做"，例如大量的刷新頁面、大量的添加購物車、雙十一零點大量的下單等都屬於此類操做。對系統來講，這些操做能夠抽象爲"讀請求"和"寫請求"，這兩種熱點請求的處理方式截然不同，讀請求的優化空間要大一些，而寫請求的瓶頸通常都在存儲層，優化思路就是根據CAP理論作平衡。

"熱點數據"，就是用戶的熱點請求對應的數據。熱點數據又分爲"靜態熱點數據和"動態熱點數據"

靜態熱點數據：就是可以提早預測的熱點數據。例如，經過賣家報名的方式提早篩選出來，經過報名系統對這些熱點商品進行達標。還能夠經過大數據分析來提早發現熱點商品，好比咱們分析歷史成交記錄、用戶的購物車記錄，來發現哪些商品可能更熱門、更好賣。

動態熱點數據：就是不能被提早預測到，系統在運行過程當中臨時產生的熱點。例如，賣家經過作廣告，使商品一會兒就火了。

熱點操做使用戶的行爲，咱們很差改變，但能作一些限制和保護，後面主要針對熱點數據來介紹如何進行優化。

發現熱點數據

咱們要有一個機制提早來區分普通商品和秒殺商品

發現靜態熱點數據

實現方式使經過一個運營系統，把參加活動的商品進行打標，而後經過一個後臺系統對這些熱點商品進行預處理，如提早進行緩存。這種方式會由兩個問題，一是增長賣家的使用成本，二使實時性不好。

不過，除了提早報名的方式，還能夠聽過買家天天訪問的商品進行大數據計算，統計topN的商品，咱們能夠認爲topN的商品就是熱點商品。

發現動態熱點數據

靜態熱點數據句實時性較差，咱們可使系統能在秒級內發現熱點商品，可以動態的實時發現熱點不只對秒殺商品有價值，對其餘熱賣商品也一樣有價值。

1. 構建一個異步的系統，它能夠收集交易鏈路上各個環節中的中間件產品熱點key，如nginx、緩存、RPC服務框架這些中間
2. 創建一個熱點上報和能夠按照需求訂閱的熱點服務的下發規範，主要目的是經過交易鏈路上各個系統（包括詳情、購物車、交易、優惠、庫存、物流等）訪問的時間差，把上游已經發現的熱點透傳給下游系統，提早作好保護。好比，對於大促高峯期，詳情繫統是最先知道的，在同一接入層上Nginx模塊統計的熱點URL。
3. 將上游系統手機的熱點數據發送到熱點服務檯，而後下游系統（如交易系統）就會知道哪些商品會被頻繁調用，而後作熱點保護。

以下圖，其中用戶訪問商品時通過的路徑有不少，咱們主要是依賴前面的導購頁面（包括首頁、搜索頁面、商品詳情、購物車等）提早識別哪些商品的訪問量高，經過這些系統中的中間件來手機熱點數據，並記錄到日誌中。

經過部署在每臺機器上的Agent把日誌彙總到聚合和分析集羣中，而後把符合必定規則的熱點數據，經過訂閱分發系統在推送到相應的系統中。你能夠是把熱點數據填充到Cache中，或者直接推送到應用服務器的內存中，還能夠對這些數據進行攔截，總之下游系統能夠訂閱這些數據，而後根據本身的需求決定如何處理這些數據。

根據經驗須要總結幾點注意事項：

1. 熱點服務後臺抓取熱點數據日誌最好採用異步方式，由於「異步」一方面便於保證通用性，另外一方面又不影響業務系統和中間件產品的主流程。
2. 熱點服務發現和中間件自身的熱點保護模塊並存，每一箇中間件和應用還須要保護本身。熱點服務檯提供熱點數據的手機和訂閱服務，便於把各個系統的熱點數據透明出來。
3. 熱點發現要作到接近實時（3s內完成熱點數據的發現），由於只有作到接近實時，動態發現纔有意義，才能實時的對下游系統提供保護。

處理熱點數據

處理熱點數據一般有三種思路：優化，限制，隔離

優化：優化熱點數據最有效的辦法就是緩存熱點數據，若是熱點數據作了動靜分離，那麼能夠長期緩存靜態數據。可是，緩存熱點數據更多的是「臨時緩存」，即不論是靜態數據仍是動態數據，都用一個隊列短暫的緩存數秒鐘，因爲隊列長度有限，能夠採用LRU淘汰算法替換。

限制：限制更可能是一種保護機制，限制的辦法不少，例如對被訪問的商品id作一致性hash，而後根據hash作分桶，每一個分桶設置一個處理隊列，這樣能夠把熱點商品限制在一個請求隊列裏，防止因某些熱點商品佔用太多服務器資源，而使其餘請求始終得不到服務器的處理資源。

隔離：將熱點數據隔離出來，不要讓1%的請求影響到另外的99%，隔離出來後更方便對這1%的請求作針對性優化。

咱們能夠對如下幾個層次實現隔離：

1. 業務隔離。把秒殺作成一種營銷活動，賣家要參加秒殺這種營銷活動須要單獨報名，從技術上來講，賣家報名後對咱們來講就有了已知熱點，所以能夠提早作好預熱。
2. 系統隔離。系統隔離更多的是運行時的隔離，能夠經過分組部署的方式和另外99%分開。秒殺能夠申請單獨的域名，目的也是讓請求落到不一樣的集羣中。
3. 數據隔離。秒殺所調用的數據大部分都是熱點數據，好比會啓用單獨的Cache集羣或者Mysql數據庫來放熱點數據，目的也是不想0.01%的數據有機會影響99.99%數據

實現隔離有不少方法。好比，你能夠按照用戶區分，給不一樣的用戶分配不一樣的cookie，在接入層，路由不一樣的服務的服務接口中；再好比，你還能夠在接入層針對URL中不一樣Path來設置限流策略。服務層調用不一樣的服務接口，以及數據層經過給數據打標來區分等等這些措施，其目的都是把已經識別出來的熱點請求和普通請求區分開。