對于雙十一來說，最激動人心的無疑就是秒殺商品了，在限定的時間內，以最便宜的價格，搶到商品。有的人可能會問，那么秒殺系統都是怎么樣的呢？我們公司規模比較小，怎么合適的設計秒殺系統呢？今天小編就給大家介紹幾種秒殺系統的設計。

在這幾種秒殺系統的設計中，最基本的組件就是redis，那么秒殺服務為什么都用redis？答案：性能好。redis基于內存讀取數據，而傳統的數據庫是基于磁盤讀取數據。在使用redis數據庫時，用戶請求來了之后，后端直接去內存獲取數據，并且同步把數據寫入磁盤，返回給到前端。使用mysql數據庫時，用戶請求來了之后，后端需要去磁盤獲取數據，再返回給到前端。從數據的獲取流程來看，Redis很快，并且通過redis性能測試數據，redis單線程QPS達到40000+，能夠扛住大量的用戶請求，因此實現秒殺系統，使用redis是最好的選擇。

方案1只使用Redis

對于小公司或個人創業者來說，用戶規模沒有多大，技術人員也有限，在資源有限的情況下，采取這個方案是最合適的。

通過PHP+Mysql+Linux服務器搭建一個電商網站，在借助Redis實現促銷秒殺。小A創建了電商平臺shopping，在里面售賣自己平時不用的耳機、鍵盤、鼠標、電腦，并且把其它同事閑置的電子設備也放在了shopping平臺上進行售賣，為了吸引更多的用戶來平臺購買商品，他想出來一個好主意，就是搞促銷，將平臺的Mac電腦100元出售，總共5臺。促銷信息在網站放出來后，一下子吸引來了很多用戶。他是這么實現秒殺系統的，用戶請求過來，第一步去Redis請求是否有庫存數據，如果有的話，則將庫存減1，成功創建訂單，秒殺成功，如果沒有數據的話，則不能創建訂單，秒殺失敗。

方案2限流+使用redis

對于有一定業務規模，但是開發資源比較緊張的公司，可以采取這種模式。相比方案1，它增加了一個限流機制，通過訪問數的限制，提高了系統性能。還是剛剛的例子，小A創建的二手電子交易平臺，隨著質量不錯、價格合適，積累了一定量的用戶。有了用戶就需要運營了，因此他也搞搞活動促銷啥的，在雙十一99元買小米手機，總共50臺，促銷信息在網站上放出，這時候一下子來了100多個用戶，每次都需要去請求redis減庫存比較耗費性能，因此在限流算法處設置每秒最多請求20個，超過的請求就排隊等著。

方案3設置固定機器的庫存+redis

對于業務規模中型時，開發資源比較緊張的公司，可以采取這種模式。當業務發展到中型規模時，系統一般會采用集群模式進行部署，也就是把服務部署在多臺機器上，同時對外提供服務，提升性能。這時候運營人員可以設置每臺機器能處理的最多庫存數量，當用戶請求進來后，程序判斷總請求量與機器庫存量大小，如果較小則請求成功，可以購買，如果較大則請求失敗。

方案4實時輪詢庫存+redis

對于業務中大型規模的公司來說，比如有數10萬用戶，雖然開發成本高，但由于用戶規模、團隊規模有一定積累，這種方案是比較適合的。在方案3中主要是靠運營人員或運維根據工作經驗判斷設置的閾值，不夠靈活。同一件商品，因為不同地域人民的消費能力都不一樣，在北京區域的售賣情況和在成都云南的售賣肯定不一樣。通過在算法中增加多協程判斷秒殺現況，動態的擴縮容。當用戶過來時，輪詢算法初步判斷庫存是否為空，如果為空則秒殺結束，如果不為空，則進入排隊（用戶感受就是加入購物車但無法支付），所有的用戶請求進入排隊隊列后，輪詢算法再次判斷庫存情況，決定多少請求可以出隊列，出隊列的請求用戶就可以成功秒殺了。

方案5前端限流+后端限流+實時輪詢+redis

對于業務體量比較大的公司，比如京東、淘寶、拼多多這種規模級別，服務上億的用戶，研發資源充裕，就可以采用這種方案。當用戶在前端發起請求后，通過CDN（內容分發網絡）前端可以把商品信息等靜態頁面信息部署在離用戶請求最近的地方，加快用戶訪問服務，當用戶請求進入后端后，通過Nginx負載均衡將請求分發到不同的秒殺服務集群，秒殺服務將信息寫入Redis主數據庫，再從Redis從數據庫獲取信息，Redis的主從部署、讀寫分離，更好的保障了服務高可用，最后再通過MQ消息隊列來做流量的削峰（超過閾值請求就進不來了，商品售完了）、用戶請求的排隊，實現了高并發、高可用、高性能的秒殺系統。

通過本文秒殺系統設計的介紹，相信你已經非常清晰秒殺系統的設計了。趕緊動手設計一個秒殺系統，助力你的業務吧。一個好的秒殺系統設計，幫你的KPI完成的更好，獲得更好的績效噢！