《秒殺系統架構分析與實戰 》

說到高併發，其實咱們中國互聯網人最有發言權。中國人口最多，並且特有的社會結構剛好是互聯網精神發揮的沃土，因此互聯網行業在中國的迅猛發展也屬情理之中。而中國現實社會中的地域發展不平衡、產業結構過分區域化、交通不夠便利及小企業信息不順暢等一道道壁壘，反而成就了電商的獨特的商業空間。

伴隨着電商的蓬勃發展，搶購和秒殺活動做爲營銷的重要手段，也對電商系統提出了愈來愈高的要求。當雙十一已經從一個簡單的噱頭演變爲可讓全民熬夜萬衆秒殺的頭條事件時，電商系統所面對的高併發壓力毫不亞於春節的微信紅包系統。

 

今天，咱們就從實戰的角度，對電商的搶購秒殺系統作一次深刻完全的解析：

 

 

 

1 秒殺業務分析

 

1. 正常電子商務流程

   （1）查詢商品；（2）建立訂單；（3）扣減庫存；（4）更新訂單；（5）付款；（6）賣家發貨

2. 秒殺業務的特性

   （1）低廉價格；（2）大幅推廣；（3）瞬時售空；（4）通常是定時上架；（5）時間短、瞬時併發量高；

 

 

 

2 秒殺技術挑戰

 

假設某網站秒殺活動只推出一件商品，預計會吸引1萬人參加活動，也就說最大併發請求數是10000，秒殺系統須要面對的技術挑戰有：

 

 

 

1. 對現有網站業務形成衝擊

   秒殺活動只是網站營銷的一個附加活動，這個活動具備時間短，併發訪問量大的特色，若是和網站原有應用部署在一塊兒，必然會對現有業務形成衝擊，稍有不慎可能致使整個網站癱瘓。

   解決方案：將秒殺系統獨立部署，甚至使用獨立域名，使其與網站徹底隔離。

    

2. 高併發下的應用、數據庫負載

   用戶在秒殺開始前，經過不停刷新瀏覽器頁面以保證不會錯過秒殺，這些請求若是按照通常的網站應用架構，訪問應用服務器、鏈接數據庫，會對應用服務器和數據庫服務器形成負載壓力。

   解決方案：從新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面內容靜態化，用戶請求不須要通過應用服務。

    

3. 忽然增長的網絡及服務器帶寬

   假設商品頁面大小200K（主要是商品圖片大小），那麼須要的網絡和服務器帶寬是2G（200K×10000），這些網絡帶寬是由於秒殺活動新增的，超過網站平時使用的帶寬。

   解決方案：由於秒殺新增的網絡帶寬，必須和運營商從新購買或者租借。爲了減輕網站服務器的壓力，須要將秒殺商品頁面緩存在CDN，一樣須要和CDN服務商臨時租借新增的出口帶寬。

    

4. 直接下單

   秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點以前，只能瀏覽商品信息，不能下單。而下單頁面也是一個普通的URL，若是獲得這個URL，不用等到秒殺開始就能夠下單了。

   解決方案：爲了不用戶直接訪問下單頁面URL，須要將改URL動態化，即便秒殺系統的開發者也沒法在秒殺開始前訪問下單頁面的URL。辦法是在下單頁面URL加入由服務器端生成的隨機數做爲參數，在秒殺開始的時候才能獲得。

    

5. 如何控制秒殺商品頁面購買按鈕的點亮

   購買按鈕只有在秒殺開始的時候才能點亮，在此以前是灰色的。若是該頁面是動態生成的，固然能夠在服務器端構造響應頁面輸出，控制該按鈕是灰色還 是點亮，可是爲了減輕服務器端負載壓力，更好地利用CDN、反向代理等性能優化手段，該頁面被設計爲靜態頁面，緩存在CDN、反向代理服務器上，甚至用戶瀏覽器上。秒殺開始時，用戶刷新頁面，請求根本不會到達應用服務器。

    

   解決方案：使用JavaScript腳本控制，在秒殺商品靜態頁面中加入一個JavaScript文件引用，該JavaScript文件中包含 秒殺開始標誌爲否；當秒殺開始的時候生成一個新的JavaScript文件（文件名保持不變，只是內容不同），更新秒殺開始標誌爲是，加入下單頁面的URL及隨機數參數（這個隨機數只會產生一個，即全部人看到的URL都是同一個，服務器端能夠用redis這種分佈式緩存服務器來保存隨機數），並被用戶瀏覽器加載，控制秒殺商品頁面的展現。這個JavaScript文件的加載能夠加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理服務器緩存。

    

   這個JavaScript文件很是小，即便每次瀏覽器刷新都訪問JavaScript文件服務器也不會對服務器集羣和網絡帶寬形成太大壓力。

    

6. 如何只容許第一個提交的訂單被髮送到訂單子系統

   因爲最終可以成功秒殺到商品的用戶只有一個，所以須要在用戶提交訂單時，檢查是否已經有訂單提交。若是已經有訂單提交成功，則須要更新 JavaScript文件，更新秒殺開始標誌爲否，購買按鈕變灰。事實上，因爲最終可以成功提交訂單的用戶只有一個，爲了減輕下單頁面服務器的負載壓力， 能夠控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其餘用戶直接進入秒殺結束頁面。

    

   解決方案：假設下單服務器集羣有10臺服務器，每臺服務器只接受最多10個下單請求。在尚未人提交訂單成功以前，若是一臺服務器已經有十單了，而有的一單都沒處理，可能出現的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結束頁面，再刷新一下頁面，有可能被一單都沒有處理的服務器處理，進入了填寫訂單的頁面，能夠考慮經過cookie的方式來應對，符合一致性原則。固然能夠採用最少鏈接的負載均衡算法，出現上述狀況的機率大大下降。

    

7. 如何進行下單前置檢查

   若是超過10條，直接返回已結束頁面給用戶；

   若是未超過10條，則用戶可進入填寫訂單及確認頁面；

   已超過秒殺商品總數，返回已結束頁面給用戶；

   未超過秒殺商品總數，提交到子訂單系統；

• 檢查全局已提交訂單數目：

• 下單服務器檢查本機已處理的下單請求數目：

   

   

8. 秒殺通常是定時上架

   該功能實現方式不少。不過目前比較好的方式是：提早設定好商品的上架時間，用戶能夠在前臺看到該商品，可是沒法點擊「當即購買」的按鈕。可是須要考慮的是，有人能夠繞過前端的限制，直接經過URL的方式發起購買，這就須要在前臺商品頁面，以及bug頁面到後端的數據庫，都要進行時鐘同步。越在後端控制，安全性越高。

   定時秒殺的話，就要避免賣家在秒殺前對商品作編輯帶來的不可預期的影響。這種特殊的變動須要多方面評估。通常禁止編輯，如需變動，能夠走數據訂正多的流程。

    

9. 減庫存的操做

   有兩種選擇，一種是拍下減庫存 另一種是付款減庫存；目前採用的「拍下減庫存」的方式，拍下就是一瞬間的事，對用戶體驗會好些。

    

10. 庫存會帶來「超賣」的問題：售出數量多於庫存數量

    因爲庫存併發更新的問題，致使在實際庫存已經不足的狀況下，庫存依然在減，致使賣家的商品賣得件數超過秒殺的預期。

     

    方案：採用樂觀鎖

     

     

    update auction_auctions setquantity = #inQuantity#where auction_id = #itemId# and quantity = #dbQuantity#

     

11. 秒殺器的應對

    秒殺器通常下單個購買及其迅速，根據購買記錄能夠甄別出一部分。能夠經過校驗碼達到必定的方法，這就要求校驗碼足夠安全，不被破解，採用的方式有：秒殺專用驗證碼，電視公佈驗證碼，秒殺答題。

 

 

 

3 秒殺架構原則

 

1. 儘可能將請求攔截在系統上游

   傳統秒殺系統之因此掛，請求都壓倒了後端數據層，數據讀寫鎖衝突嚴重，併發高響應慢，幾乎全部請求都超時，流量雖大，下單成功的有效流量甚小【一趟火車其實只有2000張票，200w我的來買，基本沒有人能買成功，請求有效率爲0】。

    

2. 讀多寫少的經常使用多使用緩存

   這是一個典型的讀多寫少的應用場景【一趟火車其實只有2000張票，200w我的來買，最多2000我的下單成功，其餘人都是查詢庫存，寫比例只有0.1%，讀比例佔99.9%】，很是適合使用緩存。

 

 

 

4 秒殺架構設計

 

秒殺系統爲秒殺而設計，不一樣於通常的網購行爲，參與秒殺活動的用戶更關心的是如何能快速刷新商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情等用戶體驗細節，所以秒殺系統的頁面設計應儘量簡單。

 

 

 

商品頁面中的購買按鈕只有在秒殺活動開始的時候才變亮，在此以前及秒殺商品賣出後，該按鈕都是灰色的，不能夠點擊。

 

 

 

下單表單也儘量簡單，購買數量只能是一個且不能夠修改，送貨地址和付款方式都使用用戶默認設置，沒有默認也能夠不填，容許等訂單提交後修改；只有第一個提交的訂單發送給網站的訂單子系統，其他用戶提交訂單後只能看到秒殺結束頁面。

 

 

 

要作一個這樣的秒殺系統，業務會分爲兩個階段，第一個階段是秒殺開始前某個時間到秒殺開始， 這個階段能夠稱之爲準備階段，用戶在準備階段等待秒殺； 第二個階段就是秒殺開始到全部參與秒殺的用戶得到秒殺結果， 這個就稱爲秒殺階段吧。

 

 

 

4.1 前端層設計

 

首先要有一個展現秒殺商品的頁面， 在這個頁面上作一個秒殺活動開始的倒計時， 在準備階段內用戶會陸續打開這個秒殺的頁面， 而且可能不停的刷新頁面。這裏須要考慮兩個問題：

 

1. 第一個是秒殺頁面的展現

   咱們知道一個html頁面仍是比較大的，即便作了壓縮，http頭和內容的大小也可能高達數十K，加上其餘的css， js，圖片等資源，若是同時有幾千萬人蔘與一個商品的搶購，通常機房帶寬也就只有1G~10G，網絡帶寬就極有可能成爲瓶頸，因此這個頁面上各種靜態資源首先應分開存放，而後放到cdn節點上分散壓力，因爲CDN節點遍及全國各地，能緩衝掉絕大部分的壓力，並且還比機房帶寬便宜~

2. 第二個是倒計時

   出於性能緣由這個通常由js調用客戶端本地時間，就有可能出現客戶端時鐘與服務器時鐘不一致，另外服務器之間也是有可能出現時鐘不一致。客戶端與服務器時鐘不一致能夠採用客戶端定時和服務器同步時間，這裏考慮一下性能問題，用於同步時間的接口因爲不涉及到後端邏輯，只須要將當前web服務器的時間發送給客戶端就能夠了，所以速度很快，就我之前測試的結果來看，一臺標準的web服務器2W+QPS不會有問題，若是100W人同時刷，100W QPS也只須要50臺web，一臺硬件LB就能夠了~，而且web服務器羣是能夠很容易的橫向擴展的(LB+DNS輪詢)，這個接口能夠只返回一小段json格式的數據，並且能夠優化一下減小沒必要要cookie和其餘http頭的信息，因此數據量不會很大，通常來講網絡不會成爲瓶頸，即便成爲瓶頸也能夠考慮多機房專線連通，加智能DNS的解決方案；web服務器之間時間不一樣步能夠採用統一時間服務器的方式，好比每隔1分鐘全部參與秒殺活動的web服務器就與時間服務器作一次時間同步。

3. 瀏覽器層請求攔截

   （1）產品層面，用戶點擊「查詢」或者「購票」後，按鈕置灰，禁止用戶重複提交請求;

   （2）JS層面，限制用戶在x秒以內只能提交一次請求;

 

 

 

4.2 站點層設計

 

前端層的請求攔截，只能攔住小白用戶（不過這是99%的用戶喲），高端的程序員根本不吃這一套，寫個for循環，直接調用你後端的http請求，怎麼整？

 

 

 

（1）同一個uid，限制訪問頻度，作頁面緩存，x秒內到達站點層的請求，均返回同一頁面

 

 

 

（2）同一個item的查詢，例如手機車次，作頁面緩存，x秒內到達站點層的請求，均返回同一頁面

 

 

 

如此限流，又有99%的流量會被攔截在站點層。

 

 

 

4.3 服務層設計

 

站點層的請求攔截，只能攔住普通程序員，高級黑客，假設他控制了10w臺肉雞（而且假設買票不須要實名認證），這下uid的限制不行了吧？怎麼整？

 

 

 

（1）大哥，我是服務層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去數據庫有什麼意義呢？對於寫請求，作請求隊列，每次只透過有限的寫請求去數據層，若是均成功再放下一批，若是庫存不夠則隊列裏的寫請求所有返回「已售完」；

 

 

 

（2）對於讀請求，還用說麼？cache來抗，無論是memcached仍是redis，單機抗個每秒10w應該都是沒什麼問題的；

 

 

 

如此限流，只有很是少的寫請求，和很是少的讀緩存mis的請求會透到數據層去，又有99.9%的請求被攔住了。

 

 

 

1. 用戶請求分發模塊：使用Nginx或Apache將用戶的請求分發到不一樣的機器上。

2. 用戶請求預處理模塊：判斷商品是否是還有剩餘來決定是否是要處理該請求。

3. 用戶請求處理模塊：把經過預處理的請求封裝成事務提交給數據庫，並返回是否成功。

4. 數據庫接口模塊：該模塊是數據庫的惟一接口，負責與數據庫交互，提供RPC接口供查詢是否秒殺結束、剩餘數量等信息。

 

• 用戶請求預處理模塊

  通過HTTP服務器的分發後，單個服務器的負載相對低了一些，但總量依然可能很大，若是後臺商品已經被秒殺完畢，那麼直接給後來的請求返回秒殺失敗便可，沒必要再進一步發送事務了。

• Java的併發包提供了三個經常使用的併發隊列實現，分別是：ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue。
• ArrayBlockingQueue是初始容量固定的阻塞隊列，咱們能夠用來做爲數據庫模塊成功競拍的隊列，好比有10個商品，那麼咱們就設定一個10大小的數組隊列。
• ConcurrentLinkedQueue使用的是CAS原語無鎖隊列實現，是一個異步隊列，入隊的速度很快，出隊進行了加鎖，性能稍慢。

• LinkedBlockingQueue也是阻塞的隊列，入隊和出隊都用了加鎖，當隊空的時候線程會暫時阻塞。

• 因爲咱們的系統入隊需求要遠大於出隊需求，通常不會出現隊空的狀況，因此咱們能夠選擇ConcurrentLinkedQueue來做爲咱們的請求隊列實現

原文連接： https://mp.weixin.qq.com/s?__biz=MzAxNTY1NjQzMA==&mid=401277709&idx=3&sn=cae57ddab69bea54f08430278072164c&scene=21#wechat_redirect