最新消息，10月24日，手機天貓宣布全面升級，基于用戶地理位置自動聚合周邊商圈、體驗活動、門店好貨和消費者權益，形成集線上購物、智慧商圈生活、用戶場景體驗為一體的新零售城市生活應用，未來有望成為阿里新零售城市生活入口。

現在很多電商網站都會提供秒殺系統，用于節日營銷的利器，秒殺時可以是網站瞬間訪問流量激增，促銷效果特別好，那么這種商城秒殺系統應該如何做，下面是hishop小編為大家介紹的商城秒殺系統設計方案

　　商城秒殺系統場景特點

　　秒殺時大量用戶會在同一時間同時進行搶購，網站瞬時訪問流量激增。

　　秒殺一般是訪問請求數量遠遠大于庫存數量，只有少部分用戶能夠秒殺成功。

　　秒殺業務流程比較簡單，一般就是下訂單減庫存。

　　商城秒殺架構設計理念

　　限流： 鑒于只有少部分用戶能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進入服務后端。

　　削峰：對于秒殺系統瞬時會有大量用戶涌入，所以在搶購一開始會有很高的瞬間峰值。高峰值流量是壓垮系統很重要的原因，所以如何把瞬間的高流量變成一段時間平穩的流量也是設計秒殺系統很重要的思路。實現削峰的常用的方法有利用緩存和消息中間件等技術。

　　異步處理：秒殺系統是一個高并發系統，采用異步處理模式可以極大地提高系統并發量，其實異步處理就是削峰的一種實現方式。

　　內存緩存：秒殺系統最大的瓶頸一般都是數據庫讀寫，由于數據庫讀寫屬于磁盤IO，性能很低，如果能夠把部分數據或業務邏輯轉移到內存緩存，效率會有極大地提升。

　　可拓展：當然如果我們想支持更多用戶，更大的并發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了。像淘寶、京東等雙十一活動時會增加大量機器應對交易高峰。

　　商城秒殺系統設計方案

　　對架構師來說是一大挑戰。 只談技術上的業務描述，秒殺一般分為秒殺前、秒殺中、秒殺后三個階段，各個階段的需求如下：

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

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

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

　　挑戰在哪

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

　　所以，方案呢

　　對于秒殺前后單頁面的大量訪問，處理起來很簡單，提前預熱把秒殺頁面放入cdn，大量的請求就可以抗住了。這里有一些需要注意的點。

　　一是cdn放的是靜態頁面，秒殺需要判斷秒殺開始，這個可以使用動態加載js的方式(網頁)，從cdn去請求一個js(秒殺開始后再生成)，該js負責跳轉到秒殺頁面(秒殺開始后再生成，避免作弊)，如果是app，可以用webview或者請求一個cdn上的文件也是可以的。有人說為什么不直接請求接口來獲取秒殺開始標識，當然是可以的，但是cdn是部署到全國各地的，如果請求服務器，這部分量會占用一部分服務器資源，秒殺誒，能節約資源來進行后續請求就節約啊，不然掛了不好看啊。

　　二是怎么判斷秒殺是否開始，秒殺基本都是約定好在某個時間點開始，所以一種直接的想法就是靠時間咯。這的確是一種做法，但不是很好，首先是因為秒殺為了分散量，多個商品的秒殺就算是一個時間點，也應該分開進行，這樣緩解系統壓力;其次就是為了公平性，這個開始時間會在一定范圍內有隨機性，這樣由于用戶看到頁面的時間隨機，不用只拼網速啦，人品也是有用的;還有就是秒殺開始后還有其他工作要做，比如刷cdn放js，生成秒殺頁面等，時間在分布式系統里是最不靠譜的了(服務器時間是有差別的)，會導致數據問題(比如js生成了，秒殺頁面還沒有出來，用戶一堆404)，用戶會罵娘的。

　　所以一般會抽象一個發令器出來(是的，程序來源于生活。。。)，秒殺系統激活發令器，秒殺開始，下游其它業務開始處理，這里可以定義這些業務的處理順序，秒殺系統里可以配置何時發令，當然也可以有隨機的規則。消息中間件出現了，這里發令器發令后，下游的業務就是通過消息中間件得到的秒殺開始的信號!!很多解決不了的問題往往是因為視角不對，以更高的視角看問題，很多問題往往只缺一個抽象。

　　秒殺中的最大壓力就是對商品庫存的并發爭搶，就像商場大促銷，就那么兩件，一堆大媽沖上去搶，各個身懷絕技，商場導購小妹沒點武藝還真是抗不住。這時候可以參考之前文章中的異步減庫存的形式來做，只是這里是異步下訂單。說具體方案之前，先看看這個業務場景要做什么?其實就是在解決一萬個人同時拿著錢來東西，但是東西只有十件，你賣給誰的問題，只要沒給錢，那我東西不給你就沒問題，給了錢就必須拿到東西。

　　所以這里我們可以對來買東西的人強制他們排隊，先到先得，并且排隊的數據少量丟失是可以接受的，后面拍著那么多人呢，不怕賣不完。那最后的方案就是，用戶點擊秒殺按鈕后，加入秒殺隊列(限制長度)，加入成功則告知正在秒殺，否則直接跳到秒殺結束頁面。對于秒殺隊列中的用戶，則進行寫訂單減庫存處理處理，并且記錄成功與失敗，商品秒殺完成后，標記秒殺結束，并且可以清空秒殺隊列，避免后面重復判斷和處理。用戶端輪詢(可以采用長輪詢，時效性好)結果，如果秒殺結束并且自己沒有秒殺成功，則跳轉到秒殺結束頁面，否則繼續等待，如果秒殺成功則跳轉到秒殺成功頁面，支付就是后面的事情了。

　　這里有幾個點需要關注，一是作弊，就是驗證碼，各種策略各種造型的驗證碼;

　　二是時效性，秒殺完后一段時間(比如半個小時)沒付款，應該將該筆秒殺標記無效，并且把庫存回補。消息中間件再次大顯身手，秒殺隊列，這里需要消息中間件提供限長隊列功能(不限長，先查詢再入隊也是可以的，只是要把握好這個時間間隔可能加入的多余數據對消息中間件的影響)，清空隊列功能(沒有也可以，只是不能更快的釋放壓力)。當然除了這些，還有限流功能，接入層只允許系統可負載流量進入，超過一定負載就采取措施緩解流量進入(比如驗證碼。。。)。

　　可以看到，對于秒殺中功能，基本就是采取逐級降低流量的方法(大流量系統的重要思路)，只讓不過分高于有效流量的流量進入后端真正的業務系統，保證業務系統不宕機。還有一個原則就是讀比寫更容易擴展，無業務系統比業務系統更容易擴展，所以應該化寫為讀(下訂單變為查詢訂單)，降低業務系統壓力(前端接入層攔截無效流量)。