今天我從 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;
        } 
    }

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

2.3 頁面優化細節

降低交互的壓力

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

安全控制

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

2.4 Redis集群的應用

1. 分布式鎖（悲觀鎖）
2. 緩存熱點數據（庫存）：如果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個事務
• 分庫以后引入分布式事務問題,為了保證用戶體驗，最好還是通過日志分析來人工維護，否則阻塞太嚴重，并發差。