業務描述

現在電商企業一大把，除了某寶、某東等大鱷，還有各種街、某說、某會、沒有品等創業明星，以及蘇寧、國美等傳統企業的電商部門，可謂百花齊放。電商以運營為基礎，各種活動、購物節層出不窮，秒殺可謂是其中的一朵奇葩——價格低到不要不要的。由于好貨超低價（大多是一元），秒殺會吸引大量的尖峰流量聚集，對架構師來說是一大挑戰。 只談技術上的業務描述，秒殺一般分為秒殺前、秒殺中、秒殺后三個階段，各個階段的需求如下：

秒殺前，用戶訪問秒殺寶貝描述頁，不斷刷新，等待秒殺開始。

秒殺中，用戶點擊秒殺按鈕，洪水般的流量瞬間涌入系統，都想走在前面，搶到寶貝。

秒殺后，秒殺結束，商品已被搶完或者秒殺時間已過，用戶訪問秒殺結束頁面，整個秒殺階段結束。

挑戰在哪

秒殺前，大量用戶頻發刷新秒殺頁面，都想第一個看到秒殺開始，越臨近開始時間，刷新越頻繁，這時候對系統會有巨大的讀壓力。 秒殺中，用戶的秒殺請求短時間內持續涌入，前端訪問量暴增，并且會牽扯到寫庫的需求，還有在對于單一熱點商品庫存判斷和遞減，由于寫庫是排他操作，一個一個排隊處理，數據庫寫壓力很大。 秒殺后，和秒殺前差不多，短時間內單頁面很多用戶訪問，但時間一過，頁面就沒有訪問量了。

所以，方案呢

對于秒殺前后單頁面的大量訪問，處理起來很簡單，提前預熱把秒殺頁面放入cdn，大量的請求就可以抗住了。這里有一些需要注意的點，一是cdn放的是靜態頁面，秒殺需要判斷秒殺開始，這個可以使用動態加載js的方式（網頁），從cdn去請求一個js（秒殺開始后再生成），該js負責跳轉到秒殺頁面（秒殺開始后再生成，避免作弊），如果是app，可以用webview或者請求一個cdn上的文件也是可以的。有人說為什么不直接請求接口來獲取秒殺開始標識，當然是可以的，但是cdn是部署到全國各地的，如果請求服務器，這部分量會占用一部分服務器資源，秒殺誒，能節約資源來進行后續請求就節約啊，不然掛了不好看啊。二是怎么判斷秒殺是否開始，秒殺基本都是約定好在某個時間點開始，所以一種直接的想法就是靠時間咯。這的確是一種做法，但不是很好，首先是因為秒殺為了分散量，多個商品的秒殺就算是一個時間點，也應該分開進行，這樣緩解系統壓力；其次就是為了公平性，這個開始時間會在一定范圍內有隨機性，這樣由于用戶看到頁面的時間隨機，不用只拼網速啦，人品也是有用的；還有就是秒殺開始后還有其他工作要做，比如刷cdn放js，生成秒殺頁面等，時間在分布式系統里是最不靠譜的了（服務器時間是有差別的），會導致數據問題（比如js生成了，秒殺頁面還沒有出來，用戶一堆404），用戶會罵娘的。所以一般會抽象一個發令器出來（是的，程序來源于生活。。。），秒殺系統激活發令器，秒殺開始，下游其它業務開始處理，這里可以定義這些業務的處理順序，秒殺系統里可以配置何時發令，當然也可以有隨機的規則。消息中間件出現了，這里發令器發令后，下游的業務就是通過消息中間件得到的秒殺開始的信號！！很多解決不了的問題往往是因為視角不對，以更高的視角看問題，很多問題往往只缺一個抽象。

秒殺中的最大壓力就是對商品庫存的并發爭搶，就像商場大促銷，就那么兩件，一堆大媽沖上去搶，各個身懷絕技，商場導購小妹沒點武藝還真是抗不住。這時候可以參考之前文章中的異步減庫存的形式來做，只是這里是異步下訂單。說具體方案之前，先看看這個業務場景要做什么？其實就是在解決一萬個人同時拿著錢來東西，但是東西只有十件，你賣給誰的問題，只要沒給錢，那我東西不給你就沒問題，給了錢就必須拿到東西。所以這里我們可以對來買東西的人強制他們排隊，先到先得，并且排隊的數據少量丟失是可以接受的，后面拍著那么多人呢，不怕賣不完。那最后的方案就是，用戶點擊秒殺按鈕后，加入秒殺隊列（限制長度），加入成功則告知正在秒殺，否則直接跳到秒殺結束頁面。對于秒殺隊列中的用戶，則進行寫訂單減庫存處理處理，并且記錄成功與失敗，商品秒殺完成后，標記秒殺結束，并且可以清空秒殺隊列，避免后面重復判斷和處理。用戶端輪詢（可以采用長輪詢，時效性好）結果，如果秒殺結束并且自己沒有秒殺成功，則跳轉到秒殺結束頁面，否則繼續等待，如果秒殺成功則跳轉到秒殺成功頁面，支付就是后面的事情了。這里有幾個點需要關注，一是作弊，就是驗證碼，各種策略各種造型的驗證碼；二是時效性，秒殺完后一段時間（比如半個小時）沒付款，應該將該筆秒殺標記無效，并且把庫存回補。消息中間件再次大顯身手，秒殺隊列，這里需要消息中間件提供限長隊列功能（不限長，先查詢再入隊也是可以的，只是要把握好這個時間間隔可能加入的多余數據對消息中間件的影響），清空隊列功能（沒有也可以，只是不能更快的釋放壓力）。當然除了這些，還有限流功能，接入層只允許系統可負載流量進入，超過一定負載就采取措施緩解流量進入（比如驗證碼。。。）。可以看到，對于秒殺中功能，基本就是采取逐級降低流量的方法（大流量系統的重要思路），只讓不過分高于有效流量的流量進入后端真正的業務系統，保證業務系統不宕機。還有一個原則就是讀比寫更容易擴展，無業務系統比業務系統更容易擴展，所以應該化寫為讀（下訂單變為查詢訂單），降低業務系統壓力（前端接入層攔截無效流量）。

秒殺后的方案和秒殺前差不多，不再贅述。

最后說兩句

本質，本質，本質！ 抓住本質看問題，不要為了解決問題而解決問題！

本文首發來自架構小站——淺談秒殺系統