秒殺系統技術解剖

文章首發於公衆號:松花皮蛋的黑板報
做者就任於京東,在穩定性保障、敏捷開發、高級JAVA、微服務架構有深刻的理解

咱們知道秒殺類的活動對整個運營貢獻是最大的，它的特色是瞬間流量俱增、請求數量遠大於庫存，致使保證下單扣庫存準確性難度大，那咱們前端、後端怎麼作才能保證呢？下面是個人一些思考。

先來講說總體的設計理念，秒殺類的活動光靠水平擴展擴增機器只能是個備選方案，它的成本和收益不對等。那咱們就應該儘可能利用有效的資源最大化處理業務，可從限流、異步處理、內存緩存角度考慮。

接下來講說具體的落地方案。秒殺類的活動前端通常會展現商品描述、秒殺價格、已售比例、時間提示，這些內容基本上是不變的，那咱們能夠經過內容分發CDN機制來將頁面靜態化，減小動態元素。前端還須要減小用戶提交次數，用戶提交以後按鈕置灰，禁止重複提交，可是別忘記了還有刷子這個灰色產業鏈，因此後端還須要作一些限制。

在後端的服務控制層針對同一訪問UID,限制請求頻率。或者先把請教都寫到消息隊列中緩存一下，邏輯層訂閱消息減庫存，減庫存成功的請求返回秒殺成功，失敗的返回秒殺結束。甚至，咱們能夠利用緩存來應對讀寫請求，首先把庫存信息同步到Redis緩存中，因此的減庫存操做都Redis中進行，而後同步到數據庫中。實際上，這些還遠遠不夠，咱們還須要考慮如下場景。

場景一是同一個帳號，一次性發出多個請求。咱們能夠利用Redis內容緩存來判斷用戶是否已參加過了活動，寫入一個標誌位，結合樂觀鎖特性約束只容許一個請求寫成功，成功寫入的也就是沒有記錄的才能繼續參加。

場景二是多個帳號，一次性發送多個請求。針對這種場景，咱們經過檢測指定機器IP請求頻率能夠解決，若是發現某個請求IP請求頻率太高，能夠給它彈出一個驗證碼或者直接禁止它的請求。

場景三是多個帳號，不一樣IP發送不一樣的請求。這種場景下的請求，和真實用戶行爲基本相同，想作分辨很難，須要經過帳號數據進行數據挖掘後打標，結合是否常常搶票、退票等等標識爲風控用戶。

其實秒殺類的活動最大的挑戰是如何保證高併發下的數據安全和防刷，這是一個矛與盾的博弈。總結一下今天的文章重點，針對秒殺系統，儘可能將請求攔截在系統上游，越上游越好，另外讀多寫少的多使用緩存。好，今天的分享就到這裏，歡迎分享給你的朋友。

文章來源：www.liangsonghua.me

做者介紹：京東資深工程師-梁鬆華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深刻的理解