秒殺架構設計的 7 個錦囊

今天我們從 7 個不同的維度，講講秒殺系統的架構設計，主要知識點如下：

Nginx + 前後端分離 + CDN 緩存 + 網關（限流 + 熔斷）
集羣的路由層 + Redis（緩存熱點數據、分佈式鎖)
MQ 集羣
業務處理層
數據庫層（讀寫分離、熱點隔離)

1. 秒殺業務的特點

瞬間大量的刷新頁面的操作
瞬間大量的搶寶的操作
可能有秒殺器的惡性競爭

2. 總體思路

2.1 削峯限流

前端 + Redis 攔截，只有 redis 扣減成功的請求才能進入到下游
MQ 堆積訂單，保護訂單處理層的負載，Consumer 根據自己的消費能力來取 Task，實際上下游的壓力就可控了。重點做好路由層和 MQ 的安全
引入答題驗證碼、請求的隨機休眠等措施，削峯填谷

安全保護

頁面和前端要做判斷，防止活動未開始就搶單，防止重複點擊按鈕連續搶單
防止秒殺器惡意搶單，IP 限流、UserId 限流限購、引入答題干擾答題器，並且對答題器答題時間做常理推斷
IP 黑名單、UserId 黑名單功能
過載丟棄：QPS 或者 CPU 等核心指標超過一定限額時，丟棄請求，避免服務器掛掉，保證大部分用戶可用

頁面優化，動靜分離

秒殺商品的網頁內容儘可能做的簡單：圖片小、js css 體積小數量少，內容儘可能的做到動靜分離
秒殺的搶寶過程中做成異步刷新搶寶，而不需要用戶刷新頁面來搶，降低服務器交互的壓力
可以使用 Nginx 的動靜分離，不通過傳統 web 瀏覽器獲取靜態資源
nginx 開啓 gzip 壓縮，壓縮靜態資源，減少傳輸帶寬，提升傳輸速度
或者使用 Varnish，把靜態資源緩存到內存當中，避免靜態資源的獲取給服務器造成的壓力

異步處理

redis 搶單成功後，把後續的業務丟到線程池中異步的處理，提高搶單的響應速度
線程池處理時，把任務丟到 MQ 中，異步的等待各個子系統處理（訂單系統、庫存系統、支付系統、優惠券系統）
異步操作有事務問題，本地事務和分佈式事務，但是爲了提升併發度，最好犧牲一致性。通過定時掃描統計日誌，來發現有問題的訂單，並且及時處理

熱點分離

儘量的避免秒殺功能給正常功能帶來的影響，比如秒殺把服務器某個功能拖垮了。

分離可以提升系統的容災性，但是完全的隔離的改造成本太高了，儘量藉助中間件的配置，來實現冷熱分離。

集羣節點的分離：nginx 配置讓秒殺業務走的集羣節點和普通業務走的集羣不一樣。
MQ 的分離：避免秒殺業務把消息隊列堆滿了，普通業務的交易延遲也特別厲害。
數據庫的分離：根據實際的秒殺的 QPS 來選擇，熱點數據分庫以後，增加了分佈式事務的問題，以及查詢的時候跨庫查詢性能要差一些（ShardingJDBC 有這種功能），所以要權衡以後再決定是否需要分庫
避免單點：各個環節都要盡力避免
降級：臨時關閉一些沒那麼重要的功能，比如秒殺商品的轉贈功能、紅包的提現功能，待秒殺峯值過了，設置開關，再動態開放這些次要的功能

2.2 Nginx 的設計細節

動靜分離，不走 tomcat 獲取靜態資源

 server {
    listen       8088;
    location ~ \.(gif|jpg|jpeg|png|bmp|swf)$ {  
        root    C:/Users/502764158/Desktop/test;  
    } 

    location ~ \.(jsp|do)$ {
        proxy_pass http://localhost:8082;
    }
 }

gzip 壓縮，減少靜態文件傳輸的體積，節省帶寬，提高渲染速度

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_comp_level 3;
    gzip_disable "MSIE [1-6]\.";
    gzip_types   text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png;

配置集羣負載和容災，設置失效重連的時間，失效後，定期不會再重試掛掉的節點，參數：

fail_timeout 默認爲 10s
max_fails 默認爲 1。就是說，只要某個 server 失效一次，則在接下來的 10s 內，就不會分發請求到該 server 上
proxy_connect_timeout 後端服務器連接的超時時間_發起握手等候響應超時時間

 upstream  netitcast.com {  #服務器集羣名字   
    server    127.0.0.1:8080;
    server    127.0.0.1:38083;
    server    127.0.0.1:8083;
    } 

 server {
        listen       88;
        server_name  localhost;
    location / {  
        proxy_pass http://netitcast.com;  
        proxy_connect_timeout       1;
        fail_timeout 5;
     } 
 }

集成 Varnish 做靜態資源的緩存
集成 tengine 做過載的保護

2.3 頁面優化細節

降低交互的壓力

儘量把 js、css 文件放在少數幾個裏面，減少瀏覽器和後端交互獲取靜態資源的次數
儘量避免在秒殺商品頁面使用大的圖片，或者使用過多的圖片

安全控制

時間有效性驗證：未到秒殺時間不能進行搶單，並且同時程序後端也要做時間有效性驗證，因爲網頁的時間和各自的系統時間決定，而且秒殺器可以通過繞開校驗直接調用搶單
異步搶單：通過點擊按鈕刷新搶寶，而不是刷新頁面的方式搶寶（答題驗證碼等等也是 ajax 交互）
另外，搜索公衆號 Linux 就該這樣學後臺回覆 “猴子”，獲取一份驚喜禮包。
redis 做 IP 限流
redis 做 UserId 限流

2.4 Redis 集羣的應用

分佈式鎖（悲觀鎖）
緩存熱點數據（庫存）：如果 QPS 太高的話，另一種方案是通過 localcache，分佈式狀態一致性通過數據庫來控制

分佈式悲觀鎖（參考 redis 悲觀鎖的代碼）

悲觀鎖（因爲肯定爭搶嚴重）
Expire 時間（搶到鎖後，立刻設置過期時間，防止某個線程的異常停擺，導致整個業務的停擺）
定時循環和快速反饋（for 緩存有超時設置，每次超時後，重新讀取一次庫存，還有貨再進行第二輪的 for 循環爭奪，實現快速反饋，避免沒有貨了還在持續搶鎖）

異步處理訂單

redis 搶鎖成功後，記錄搶到鎖的用戶信息後，就可以直接釋放鎖，並反饋用戶，通過異步的方式來處理訂單，提升秒殺的效率，降低無意義的線程等待
爲了避免異步的數據不同步，需要搶到鎖的時候，在 redis 裏面緩存用戶信息列表，緩存結束後，觸發搶單成功用戶信息持久化，並且定時的比對一致性

2.5 消息隊列限流

消息隊列削峯限流 (RocketMQ 自帶的 Consumer 自帶線程池和限流措施)，集羣。一般都是微服務，訂單中心、庫存中心、積分中心、用戶的商品中心

2.6 數據庫設計

拆分事務提高併發度
根據業務需求考慮分庫：讀寫分離、熱點隔離拆分，但是會引入分佈式事務問題，以及跨庫操作的難度

要執行的操作：扣減庫存、生成新訂單、生成待支付訂單、扣減優惠券、積分變動

庫存表是數據庫併發的瓶頸所在，需要在事務控制上做權衡：可以把扣減庫存設置成一個獨立的事務，其它操作成一個大的事務（訂單、優惠券、積分操作），提高併發度，但是要做好額外的 check

update 庫存表 set 庫存 = 庫存 - 1 where id=** and 庫存 > 1

2.7 答題驗證碼的設計

可以防止秒殺器的干擾，讓更多用戶有機會搶到
延緩請求，每個人的反應時間不同，把瞬間流量分散開來了

驗證碼的設計可以分爲 2 種：

驗證失敗重新刷新答題（12306）：服務器交互量大，每錯一次交互一次，但是可以大大降低秒殺器答題的可能性，因爲沒有試錯這個功能，答題一直在變
驗證失敗提示失敗，但是不刷新答題的算法：要麼答題成功，進入下單界面，要麼提示打錯，繼續答題（不刷新答題，無須交互，用 js 驗證結果)。
這種方案，可以在加載題目的時候一起加載 MD5 加密的答案，然後後臺再校驗一遍，實現類似的防止作弊的效果。好處是不需要額外的服務器交互。
MD 加密答案的算法裏面要引入 userId PK 這些因素進來來確保每次答案都不一樣而且沒有規律，避免秒殺器統計結果集

答題的驗證：除了驗證答案的正確性意外，還要統計反應時間，例如 12306 的難題，正常人類的答題速度最快是 1.5s，那麼，小於 1s 的驗證可以判定爲機器驗證

3. 注意事項

爲了提升併發，需要在事務上做妥協：

單機上拆分事務：比如扣減庫存表 +(生成待支付訂單 + 優惠券扣減 + 積分變動) 是一個大的事務，爲了提高併發，可以拆分爲 2 個事務
分庫以後引入分佈式事務問題, 爲了保證用戶體驗，最好還是通過日誌分析來人工維護，否則阻塞太嚴重，併發差。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Cm8mJRt7bHtNKXKQssWAIw