點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

提到秒殺，很多人都會覺得這是一件技術要求很高的事情，因為這涉及到超大訪問量（可能瞬間千萬倍的用戶訪問商品）、維護數據一致性（不能超賣）。

前者對性能有極高的要求，而后者又正好拉低了性能，本文談談秒殺的設計思路，并在最后給出秒殺設計的簡單模型圖。

秒殺的情景

生活中有很多秒殺的情景，例如商家促銷，像一元搶茅臺，五毛錢搶寶馬（這兒只是一個例子）。

假如一百萬人來搶十瓶茅臺，這時候肯定不能多賣出，也就是不能被大于 10 的人數搶到，通常最后時間會有一個倒計時按鈕，30，29，28，3，2，1，GO！之后躍躍欲試的人們開始搶。

這時候有以下問題需要被考慮：

• 第一是多個客戶端的時間如何保持同步，也就是讓大家看到時間是一致的，不能你顯示 3，而我這還顯示 30。

• 第二是如何保證有沒有黃牛用機器人搶。

• 第三是如何確保后端服務器可以支撐住這巨大的流量。

• ......

秒殺解決思路

有了上面的情景以及引出來的問題，來看看秒殺方案的設計思路，我們服務器如何應對這一百萬的TPS呢？

首先想到的是擴容，但這是不現實的，因為擴容需要很多很多機器，TPS 增加一萬倍對物理服務器的性能要求遠遠不止一萬倍。

另外對于一個商家來說，為了這一次促銷活動購置服務器是不劃算的，平時勢必有眾多的機器處于閑置狀態。

沒法擴容，那么也就意味著要使用其他方法，如果所有請求訪問一臺物理機器肯定不行，一百萬的數據訪問無論如何分庫分表都無濟于事，因為面對的每一條都是熱點數據，所以要用到分布式架構的思路。

秒殺的技術方案

分布式，可以降低服務器的壓力，下面開始講述秒殺的設計思路。

方案一

很明顯，要讓一百萬用戶能夠同時打開搶貨的網頁，勢必要用要到 CDN。

CDN 主要作用有兩個：

一方面是將一些不會改變的靜態資源放到離客戶端較近的邊緣服務器上。

這樣客戶端請求數據的時候可以直接從邊緣服務器獲取，降低中心服務器的壓力。

另外一方面可以把小服務部署到 CDN 結點上去，這樣，當前端頁面來問開沒開始時，這個小服務除了告訴前端開沒開始外，它還可以統計下有多少人在線。

每個小服務會把當前在線等待秒殺的人數每隔一段時間就回傳給我們的數據中心，于是我們就知道全網總共在線的人數有多少。

假設，我們知道有大約 100 萬的人在線等著搶，那么，在我們快要開始的時候，由數據中心向各個部署在 CDN 結點上的小服務上傳遞一個概率值，這個概率值為 CDN 節點人數權重乘以獲獎概率，比如說是 e。

于是，當秒殺開始的時候，這 100 萬用戶都在點下單按鈕，首先他們請求到的是 CDN 上的這些服務。

這些小服務按照?e 的量把用戶放到后面的數據中心，也就是放過去人數?e，剩下的都直接返回秒殺已結束。

方案二

利用我們分布式中限流、網關等知識，將請求層層篩選，降低最后連接到數據庫的請求。

首先也是利用 CDN 將靜態資源分發在邊緣服務器上，當進行服務請求時，先進行鑒權，鑒權主要是篩選機器人等非人工搶購，根據實際經驗，鑒權可以篩選很大一部分用戶，例如是否登錄。

當鑒權確定是真實有效的用戶之后，通過負載均衡，也就是 LVS+Keepalived 將請求分配到不同的 Nginx 上。

一般會建立 Nginx 集群，然后再通過網關集群，即使這樣還是要增加一些限流措施。

如果到這一步還是有很多請求壓到數據庫勢必撐不住，那么可以采取服務限流、服務降級等措施，進行削峰處理。

到這兒理論上流量就不高了，如果還是很高，后面就將熱點數據放進緩存集群中進行預熱，同時設置定時任務。

一方面關注數據庫與緩存的一致性，另一方面關閉超時未支付的訂單，當訂單提交之后交給任務隊列，生成訂單、修改數據庫、做好持久化工作。

架構圖如下（可點擊查看大圖）：

這就是整個“秒殺”的技術細節，是不是有點不敢相信？

與這種秒殺業務類似的還有 12306 搶票，這個也是瞬間高流量，但是上面提到的架構就不適合了，因為 12306 完全不知道用戶來是要買哪張火車票的。

不知道這個信息，很不好過濾用戶，而且用戶在買票前需要有很多查詢操作，然后在查詢中選擇自己的車票。也就意味著沒法在開始就過濾用戶。

12306 最好的應對方式，除了不要一次把所有的票放出來，而是分批在不同的時間段把票放出來。

這樣可以讓人們不要集中在一個時間點來搶票，做到人肉分流，可以降低一些并發度。

另外，12306 最好是用預售的方式，讓大家把自己的購票先輸入到系統中。

系統并不真正放票，而是把大家的需求都收集好，然后做整體統籌安排，該增加車次的增加車次，該加車廂的加車廂，這樣可以確保大家都能走。實在不行，就抽簽了。

總結

我們可以看到，解決秒殺這種特定業務場景，可以使用 CDN 的邊緣結點來扛流量，然后過濾用戶請求（限流用戶請求），來保護數據中心的系統，這樣才讓整個秒殺得以順利進行。

也可以像方案二那樣逐層過濾請求，這種業務場景和雙十一相同嗎？如果像雙 11 那樣，想盡可能多地賣出商品，那么就不像秒殺了。

這是要盡可能多地收訂單，但又不能超過庫存，其中還有大量的銀行支付，各大倉庫的庫存查詢和分配，這些都是非常慢的操作。

為了保證一致性，還要能夠扛得住像雙 11 這樣的大規模并發訪問，那么，應該怎么做呢？

使用秒殺這樣的解決方案基本上不太科學了。這個時候就需要認認真真地做高并發的架構和測試了。

需要各個系統把自己的性能調整上去，還要小心地做性能規劃，更要把分布式的彈力設計做好。

最后是要不停地做性能測試，找到整個架構的系統瓶頸，然后不斷地做水平擴展，以解決大規模的并發。

有些時候，我們總是在想數據中心的解決方案。其實，我們有時候也需要換一換思路，也許，在數據中心解決并不一定是最好的方式，放在邊緣來解決可能會更好一些。

尤其是針對一些有地域特征的業務，比如像外賣、共享單車、打車這樣的業務。

其實，把一些簡單的業務邏輯放在邊緣，比放在數據中心不但能夠有更好的性能，還有更便宜的成本。

我覺得，隨著請求量越來越大，數據也越來越多，數據中心是有點到瓶頸了，而需要邊緣結點來幫忙了。而且，這個邊緣化解決方案的趨勢也會越來越有優勢。

作者：等不到的口琴

出處：cnblogs.com/Courage129/p/14493931.html

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• 原創|OpenAPI標準規范

• 中臺不是萬能藥，關于中臺的思考和嘗試
  

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 微服務下如何解耦？對于已經緊耦合下如何重構？

• 如何構建一套高性能、高可用、低成本的視頻處理系統？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交
  

點個贊+在看，少個 bug?????

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的看完这个“秒杀”设计方案！我有点慌了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。