[轉]秒殺系統架構分析與實戰

原文出處：  陶邦仁   歡迎分享原創到 伯樂頭條

0 系列文件夾

• 秒殺系統架構
  • 秒殺系統架構分析與實戰

1 秒殺業務分析

1. 正常電子商務流程（1）查詢商品。（2）建立訂單。（3）扣減庫存；（4）更新訂單。（5）付款；（6）賣家發貨
2. 秒殺業務的特性（1）低便宜格；（2）大幅推廣；（3）瞬時售空；（4）一般是定時上架；（5）時間短、瞬時併發量高；

2 秒殺技術挑戰

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

1. 對現有站點業務形成衝擊秒殺活動僅僅是站點營銷的一個附加活動，這個活動具備時間短，併發訪問量大的特色，假設和站點原有應用部署在一塊兒。一定會對現有業務形成衝擊，稍有不慎可能致使整個站點癱瘓。解決方式：將秒殺系統獨立部署，甚至使用獨立域名。使其與站點全然隔離。

2. 高併發下的應用、數據庫負載用戶在秒殺開始前，經過不停刷新瀏覽器頁面以保證不會錯過秒殺，這些請求假設依照通常的站點應用架構，訪問應用server、鏈接數據庫，會相應用server和數據庫server形成負載壓力。解決方式：又一次設計秒殺商品頁面，不使用站點原來的商品具體頁面。頁面內容靜態化，用戶請求不需要通過應用服務。

3. 忽然添加的網絡及server帶寬假設商品頁面大小200K（主要是商品圖片大小）。那麼需要的網絡和server帶寬是2G（200K×10000），這些網絡帶寬是由於秒殺活動新增的，超過站點平時使用的帶寬。

   解決方式：由於秒殺新增的網絡帶寬。必須和運營商又一次購買或者租借。

   爲了減輕站點server的壓力，需要將秒殺商品頁面緩存在CDN，一樣需要和CDN服務商暫時租借新增的出口帶寬。

4. 直接下單秒殺的遊戲規則是到了秒殺才幹開始對商品下單購買，在此時間點以前。僅僅能瀏覽商品信息，不能下單。

   而下單頁面也是一個普通的URL，假設獲得這個URL，不用等到秒殺開始就可以下單了。

   解決方式：爲了不用戶直接訪問下單頁面URL，需要將改URL動態化。即便秒殺系統的開發人員也沒法在秒殺開始前訪問下單頁面的URL。

   辦法是在下單頁面URL添加由server端生成的隨機數做爲參數，在秒殺開始的時候才幹獲得。

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

   解決方式：使用JavaScript腳本控制，在秒殺商品靜態頁面中添加一個JavaScript文件引用，該JavaScript文件裏包括 秒殺開始標誌爲否；當秒殺開始的時候生成一個新的JavaScript文件（文件名稱保持不變。僅僅是內容不同），更新秒殺開始標誌爲是，添加下單頁面的URL及隨機數參數（這個隨機數僅僅會產生一個，即所有人看到的URL都是同一個。server端可以用redis這樣的分佈式緩存server來保存隨機數），並被用戶瀏覽器載入，控制秒殺商品頁面的展現。

   這個JavaScript文件的載入可以加上隨機版本（好比xx.js?v=32353823）。這樣就不會被瀏覽器、CDN和反向代理server緩存。

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

6. 怎樣僅僅贊成第一個提交的訂單被髮送到訂單子系統由於終於可以成功秒殺到商品的用戶僅僅有一個。所以需要在用戶提交訂單時。檢查是否已經有訂單提交。假設已經有訂單提交成功，則需要更新 JavaScript文件，更新秒殺開始標誌爲否，購買button變灰。事實上，由於終於可以成功提交訂單的用戶僅僅有一個，爲了減輕下單頁面server的負載壓力， 可以控制進入下單頁面的入口，僅僅有少數用戶能進入下單頁面，其它用戶直接進入秒殺結束頁面。解決方式：假設下單server集羣有10臺server，每臺server僅僅接受最多10個下單請求。

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

7. 怎樣進行下單前置檢查
   • 下單server檢查本機已處理的下單請求數目：

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

   假設未超過10條，則用戶可進入填寫訂單及確認頁面。

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

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

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

8. 秒殺一般是定時上架該功能實現方式很是多。

   只是眼下比較好的方式是：提早設定好商品的上架時間，用戶可以在前臺看到該商品，但是沒法點擊「立刻購買」的button。

   但是需要考慮的是。有人可以繞過前端的限制，直接經過URL的方式發起購買，這就需要在前臺商品頁面，以及bug頁面到後端的數據庫，都要進行時鐘同步。

   越在後端控制。安全性越高。定時秒殺的話。就要避免賣家在秒殺前對商品作編輯帶來的不可預期的影響。這樣的特殊的變動需要多方面評估。通常禁止編輯。如需變動，可以走數據訂正多的流程。

9. 減庫存的操做有兩種選擇，一種是拍下減庫存 第二種是付款減庫存。眼下採用的「拍下減庫存」的方式，拍下就是一瞬間的事。對用戶體驗會好些。
10. 庫存會帶來「超賣」的問題：售出數量多於庫存數量由於庫存併發更新的問題，致使在實際庫存已經不足的狀況下。庫存依舊在減，致使賣家的商品賣得件數超過秒殺的預期。

    方案：採用樂觀鎖

    1 2 3

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

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

3 秒殺架構原則

1. 儘可能將請求攔截在系統上游傳統秒殺系統之因此掛，請求都壓倒了後端數據層，數據讀寫鎖衝突嚴重，併發高響應慢，差點兒所有請求都超時，流量雖大，下單成功的有效流量甚小【一趟火車事實上僅僅有2000張票，200w我的來買，基本沒有人能買成功。請求有效率爲0】。
2. 讀多寫少的常用多使用緩存這是一個典型的讀多寫少的應用場景【一趟火車事實上僅僅有2000張票，200w我的來買，最多2000我的下單成功，其它人都是查詢庫存。寫比例僅僅有0.1%。讀比例佔99.9%】，很是適合使用緩存。

4 秒殺架構設計

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

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

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

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

4.1 前端層設計

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

1. 第一個是秒殺頁面的展現咱們知道一個html頁面仍是比較大的，即便作了壓縮。http頭和內容的大小也可能高達數十K，加上其它的css。 js，圖片等資源，假設同一時候有幾千萬人參與一個商品的搶購，通常機房帶寬也就僅僅有1G~10G。網絡帶寬就極有可能成爲瓶頸。因此這個頁面上各種靜態資源首先應分開存放，而後放到cdn節點上分散壓力，由於CDN節點遍及全國各地，能緩衝掉絕大部分的壓力。並且還比機房帶寬便宜~
2. 第二個是倒計時出於性能緣由這個通常由js調用client本地時間。就有可能出現client時鐘與server時鐘不一致。另外server之間也是有可能出現時鐘不一致。

   client與server時鐘不一致可以採用client定時和server同步時間。這裏考慮一下性能問題。用於同步時間的接口由於不涉及到後端邏輯。僅僅需要將當前webserver的時間發送給client就可以了，所以速度很是快。就我之前測試的結果來看。一臺標準的webserver2W+QPS不會有問題，假設100W人同一時候刷，100W QPS也僅僅需要50臺web。一臺硬件LB就可以了~，並且webserver羣是可以很是easy的橫向擴展的(LB+DNS輪詢)，這個接口可以僅僅返回一小段json格式的數據。並且可以優化一降低低沒必要要cookie和其它http頭的信息。因此數據量不會很是大，通常來講網絡不會成爲瓶頸，即便成爲瓶頸也可以考慮多機房專線連通，加智能DNS的解決方式；webserver之間時間不一樣步可以採用統一時間server的方式，比方每隔1分鐘所有參與秒殺活動的webserver就與時間server作一次時間同步。

3. 瀏覽器層請求攔截（1）產品層面，用戶點擊「查詢」或者「購票」後，button置灰，禁止用戶反覆提交請求;（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接口供查詢是否秒殺結束、剩餘數量等信息。

• 用戶請求預處理模塊通過HTTPserver的分發後，單個server的負載相對低了一些，但總量依舊可能很是大，假設後臺商品已經被秒殺完畢。那麼直接給後來的請求返回秒殺失敗就能夠。沒必要再進一步發送事務了。演示樣例代碼可以例如如下所看到的：

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

  package seckill; import org.apache.http.HttpRequest; /** * 預處理階段。把沒必要要的請求直接駁回，必要的請求添加到隊列中進入下一階段. */ public class PreProcessor {    // 商品是否還有剩餘    private static boolean reminds = true ;    private static void forbidden() {        // Do something.    }    public static boolean checkReminds() {        if (reminds) {            // 遠程檢測是否還有剩餘。該RPC接口應由數據庫server提供。沒必要全然嚴格檢查.            if (!RPC.checkReminds()) {                reminds = false ;            }        }        return reminds;    }    /**     * 每一個HTTP請求都要通過該預處理.     */    public static void preProcess(HttpRequest request) {        if (checkReminds()) {            // 一個併發的隊列            RequestQueue.queue.add(request);        } else {            // 假設已經沒有商品了。則直接駁回請求就能夠.            forbidden();        }    } }

  • 併發隊列的選擇

  Java的併發包提供了三個常用的併發隊列實現，各自是：ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue。

  ArrayBlockingQueue是初始容量固定的堵塞隊列，咱們可以用來做爲數據庫模塊成功競拍的隊列。比方有10個商品，那麼咱們就設定一個10大小的數組隊列。

  ConcurrentLinkedQueue使用的是CAS原語無鎖隊列實現，是一個異步隊列。入隊的速度很是快。出隊進行了加鎖。性能稍慢。

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

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

  1 2 3 4 5 6 7

  package seckill; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ConcurrentLinkedQueue; import org.apache.http.HttpRequest; public class RequestQueue {    public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<HttpRequest>(); }

• 用戶請求模塊

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  package seckill; import org.apache.http.HttpRequest; public class Processor {    /**     * 發送秒殺事務到數據庫隊列.     */    public static void kill(BidInfo info) {        DB.bids.add(info);    }    public static void process() {        BidInfo info = new BidInfo(RequestQueue.queue.poll());        if (info != null ) {            kill(info);        }    } } class BidInfo {    BidInfo(HttpRequest request) {        // Do something.    } }

• 數據庫模塊數據庫主要是使用一個ArrayBlockingQueue來暫存有可能成功的用戶請求。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

  package seckill; import java.util.concurrent.ArrayBlockingQueue; /** * DB應該是數據庫的惟一接口. */ public class DB {    public static int count = 10 ;    public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<BidInfo>( 10 );    public static boolean checkReminds() {        // TODO        return true ;    }    // 單線程操做    public static void bid() {        BidInfo info = bids.poll();        while (count-- > 0 ) {            // insert into table Bids values(item_id, user_id, bid_date, other)            // select count(id) from Bids where item_id = ?            // 假設數據庫商品數量大約總數，則標誌秒殺已完畢，設置標誌位reminds = false.            info = bids.poll();        }    } }

4.4 數據庫設計

4.4.1 基本概念

概念一「單庫」

概念二「分片」

分片解決的是「數據量太大」的問題，也就是一般說的「水平切分」。一旦引入分片，勢必有「數據路由」的概念，哪一個數據訪問哪一個庫。路由規則一般有3種方法：

1. 範圍：range長處：簡單。easy擴展缺點：各庫壓力不均（新號段更活躍）
2. 哈希：hash 【大部分互聯網公司採用的方案二：哈希分庫。哈希路由】長處：簡單，數據均衡，負載均勻缺點：遷移麻煩（2庫擴3庫數據要遷移）
3. 路由服務：router-config-server長處：靈活性強，業務與路由算法解耦缺點：每次訪問數據庫前多一次查詢

概念三「分組」

分組解決「可用性」問題，分組一般經過主從複製的方式實現。

互聯網公司數據庫實際軟件架構是：又分片，又分組（例如如下圖）

4.4.2 設計思路

數據庫軟件架構師平時設計些什麼東西呢？至少要考慮下面四點：

1. 怎樣保證數據可用性；
2. 怎樣提升數據庫讀性能（大部分應用讀多寫少，讀會先成爲瓶頸）。
3. 怎樣保證一致性；
4. 怎樣提升擴展性；

• 1. 怎樣保證數據的可用性？解決可用性問題的思路是=>冗餘怎樣保證站點的可用性？複製站點，冗餘站點怎樣保證服務的可用性？複製服務，冗餘服務

  怎樣保證數據的可用性？複製數據。冗餘數據

  數據的冗餘，會帶來一個反作用=>引起一致性問題（先不說一致性問題。先說可用性）。

• 2. 怎樣保證數據庫「讀」高可用？冗餘讀庫冗餘讀庫帶來的反作用？讀寫有延時，可能不一致

  上面這個圖是很是多互聯網公司mysql的架構，寫仍然是單點。不能保證寫高可用。

• 3. 怎樣保證數據庫「寫」高可用？冗餘寫庫採用雙主互備的方式，可以冗餘寫庫帶來的反作用？雙寫同步，數據可能衝突（好比「自增id」同步衝突）,怎樣解決同步衝突，有兩種常看法決方式：
  1. 兩個寫庫使用不一樣的初始值。一樣的步長來添加id：1寫庫的id爲0,2,4,6…；2寫庫的id爲1,3,5,7…。
  2. 不使用數據的id。業務層本身生成惟一的id，保證數據不衝突；

實際中沒有使用上述兩種架構來作讀寫的「高可用」。採用的是「雙主當主從用」的方式：

還是雙主。但僅僅有一個主提供服務（讀+寫）。另外一個主是「shadow-master」。僅僅用來保證高可用。平時不提供服務。 master掛了，shadow-master頂上（vip漂移，對業務層透明。不需要人工介入）。這樣的方式的長處：

1. 讀寫沒有延時；
2. 讀寫高可用；

不足：

1. 不能經過加從庫的方式擴展讀性能；
2. 資源利用率爲50%，一臺冗餘主沒有提供服務；

那怎樣提升讀性能呢？進入第二個話題，怎樣提供讀性能。

• 4. 怎樣擴展讀性能提升讀性能的方式大體有三種。第一種是創建索引。這樣的方式不展開，要提到的一點是，不一樣的庫可以創建不一樣的索引。寫庫不創建索引。

  線上讀庫創建線上訪問索引，好比uid；

  線下讀庫創建線下訪問索引，好比time；

  第二種擴充讀性能的方式是。添加從庫，這樣的方法你們用的比較多，但是，存在兩個缺點：

  1. 從庫越多。同步越慢；
  2. 同步越慢，數據不一致窗體越大（不一致後面說，仍是先說讀性能的提升）。

  實際中沒有採用這樣的方法提升數據庫讀性能（沒有從庫）。採用的是添加緩存。

  常見的緩存架構例如如下：

  上游是業務應用，下游是主庫，從庫（讀寫分離）。緩存。

  實際的玩法：服務+數據庫+緩存一套

  業務層不直接面向db和cache。服務層屏蔽了底層db、cache的複雜性。

  爲何要引入服務層，今天不展開，採用了「服務+數據庫+緩存一套」的方式提供數據訪問。用cache提升讀性能。

  不管採用主從的方式擴展讀性能，仍是緩存的方式擴展讀性能，數據都要複製多份（主+從。db+cache），必定會引起一致性問題。

• 5. 怎樣保證一致性？主從數據庫的一致性。一般有兩種解決方式：1. 中間件

  假設某一個key有寫操做，在不一致時間窗體內，中間件會將這個key的讀操做也路由到主庫上。這個方法的缺點是，數據庫中間件的門檻較高（百度，騰訊，阿里，360等一些公司有）。

  2. 強制讀主

  上面實際用的「雙主當主從用」的架構，不存在主從不一致的問題。

  第二類不一致，是db與緩存間的不一致：

  常見的緩存架構如上，此時寫操做的順序是：

  （1）淘汰cache；

  （2）寫數據庫。

  讀操做的順序是：

  （1）讀cache，假設cache hit則返回。

  （2）假設cache miss，則讀從庫；

  （3）讀從庫後，將數據放回cache。

  在一些異常時序狀況下，有可能從【從庫讀到舊數據（同步尚未完畢），舊數據入cache後】，數據會長期不一致。解決的方法是「緩存雙淘汰」。寫操做時序升級爲：

  （1）淘汰cache；

  （2）寫數據庫。

  （3）在經驗「主從同步延時窗體時間」後，再次發起一個異步淘汰cache的請求；

  這樣。即便有髒數據如cache。一個小的時間窗體以後，髒數據仍是會被淘汰。帶來的代價是。多引入一次讀miss（成本可以忽略）。

  除此以外，最佳實踐之中的一個是：建議爲所有cache中的item設置一個超時時間。

• 6. 怎樣提升數據庫的擴展性？原來用hash的方式路由，分爲2個庫。數據量仍是太大，要分爲3個庫，勢必需要進行數據遷移。有一個很是帥氣的「數據庫秒級擴容」方案。怎樣秒級擴容？首先，咱們不作2庫變3庫的擴容。咱們作2庫變4庫（庫加倍）的擴容（將來4->8->16）

  服務+數據庫是一套（省去了緩存），數據庫採用「雙主」的模式。

  擴容步驟：

  第一步，將一個主庫提高;

  第二步。改動配置，2庫變4庫（原來MOD2，現在配置改動後MOD4），擴容完畢。

  原MOD2爲偶的部分，現在會MOD4餘0或者2。原MOD2爲奇的部分。現在會MOD4餘1或者3；數據不需要遷移。同一時候，雙主互一樣步，一遍是餘0，一邊餘2。兩邊數據同步也不會衝突。秒級完畢擴容！

  最後，要作一些收尾工做：

  1. 將舊的雙主同步解除；
  2. 添加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務）；
  3. 刪除多餘的數據（餘0的主，可以將餘2的數據刪除掉）。

  這樣。秒級別內，咱們就完畢了2庫變4庫的擴展。

5 大併發帶來的挑戰

5.1 請求接口的合理設計

一個秒殺或者搶購頁面，一般分爲2個部分。一個是靜態的HTML等內容，另外一個就是參與秒殺的Web後臺請求接口。

一般靜態HTML等內容。是經過CDN的部署。通常壓力不大。核心瓶頸實際上在後臺請求接口上。這個後端接口，必須可以支持高併發請求。同一時候，很是重要的一點，必須儘量「快」，在最短的時間裏返回用戶的請求結果。爲了實現儘量快這一點。接口的後端存儲使用內存級別的操做會更好一點。仍然直接面向MySQL之類的存儲是不合適的，假設有這樣的複雜業務的需求，都建議採用異步寫入。

固然，也有一些秒殺和搶購採用「滯後反饋」，就是說秒殺當下不知道結果，一段時間後才幹夠從頁面中看到用戶是否秒殺成功。但是，這樣的屬於「偷懶」行爲。同一時候給用戶的體驗也很差，easy被用戶以爲是「暗箱操做」。

5.2 高併發的挑戰：必定要「快」

咱們一般衡量一個Web系統的吞吐率的指標是QPS（Query Per Second，每秒處理請求數）。解決每秒數萬次的高併發場景。這個指標很是關鍵。舉個樣例，咱們假設處理一個業務請求平均響應時間爲100ms，同一時候，系統內有20臺Apache的Webserver。配置MaxClients爲500個（表示Apache的最大鏈接數目）。

那麼，咱們的Web系統的理論峯值QPS爲（理想化的計算方式）：

1	20*500/0.1 = 100000 （10萬QPS）

咦？咱們的系統彷佛很是強大，1秒鐘可以處理完10萬的請求，5w/s的秒殺彷佛是「紙老虎」哈。

實際狀況，固然沒有這麼理想。在高併發的實際場景下，機器都處於高負載的狀態，在這個時候平均響應時間會被大大添加。

就Webserver而言，Apache打開了越多的鏈接進程，CPU需要處理的上下文切換也越多，額外添加了CPU的消耗，而後就直接致使平均響應時間添加。

所以上述的MaxClient數目，要依據CPU、內存等硬件因素綜合考慮，絕對不是越多越好。可以經過Apache自帶的abench來測試一下。取一個合適的值。而後，咱們選擇內存操做級別的存儲的Redis，在高併發的狀態下，存儲的響應時間相當重要。網絡帶寬儘管也是一個因素，只是，這樣的請求數據包通常比較小，通常很是少成爲請求的瓶頸。負載均衡成爲系統瓶頸的狀況比較少，在這裏不作討論哈。

那麼問題來了。假設咱們的系統。在5w/s的高併發狀態下，平均響應時間從100ms變爲250ms（實際狀況。甚至不少其它）：

1	20*500/0.25 = 40000 （4萬QPS）

因而。咱們的系統剩下了4w的QPS。面對5w每秒的請求，中間相差了1w。

而後。這纔是真正的惡夢開始。舉個樣例，快速路口。1秒鐘來5部車，每秒經過5部車。快速路口運做正常。

忽然。這個路口1秒鐘僅僅能經過4部車，車流量仍然依舊，結果一定出現大塞車。

（5條車道突然變成4條車道的感受）。

同理，某一個秒內。20*500個可用鏈接進程都在滿負荷工做中。卻仍然有1萬個新來請求，沒有鏈接進程可用，系統陷入到異常狀態也是預期以內。

事實上在正常的非高併發的業務場景中，也有相似的狀況出現，某個業務請求接口出現故障，響應時間極慢，將整個Web請求響應時間拉得很是長，逐漸將Webserver的可用鏈接數佔滿。其它正常的業務請求，無鏈接進程可用。

更可怕的問題是。是用戶的行爲特色。系統越是不可用，用戶的點擊越頻繁。惡性循環終於致使「雪崩」（當中一臺Web機器掛了。致使流量分散到其它正常工做的機器上，再致使正常的機器也掛。而後惡性循環），將整個Web系統拖垮。

5.3 從新啓動與過載保護

假設系統發生「雪崩」，貿然從新啓動服務，是沒法解決這個問題的。最多見的現象是，啓動起來後，立馬掛掉。這個時候，最好在入口層將流量拒絕，而後再將從新啓動。假設是redis/memcache這樣的服務也掛了，從新啓動的時候需要注意「預熱」，並且很是可能需要比較長的時間。

秒殺和搶購的場景，流量每每是超乎咱們系統的準備和想象的。這個時候，過載保護是必要的。假設檢測到系統滿負載狀態。拒絕請求也是一種保護措施。在前端設置過濾是最簡單的方式，但是。這樣的作法是被用戶「千夫所指」的行爲。

更合適一點的是，將過載保護設置在CGI入口層，快速將客戶的直接請求返回。

6 做弊的手段：進攻與防守

秒殺和搶購收到了「海量」的請求。實際上裏面的水分是很是大的。很多用戶。爲了「搶「到商品，會使用「刷票工具」等類型的輔助工具，幫助他們發送儘量多的請求到server。

另外一部分高級用戶。製做強大的本身主動請求腳本。這樣的作法的理由也很是簡單，就是在參與秒殺和搶購的請求中。本身的請求數目佔比越多，成功的機率越高。

這些都是屬於「做弊的手段」，只是，有「進攻」就有「防守」。這是一場沒有硝煙的戰鬥哈。

6.1 同一個帳號，一次性發出多個請求

部分用戶經過瀏覽器的插件或者其它工具，在秒殺開始的時間裏，以本身的帳號，一次發送上百甚至不少其它的請求。實際上，這樣的用戶破壞了秒殺和搶購的公平性。

這樣的請求在某些沒有作數據安全處理的系統裏，也可能形成第二種破壞，致使某些推斷條件被繞過。好比一個簡單的領取邏輯。先推斷用戶是否有參與記錄，假設沒有則領取成功，最後寫入到參與記錄中。這是個很是簡單的邏輯。但是。在高併發的場景下，存在深深的漏洞。多個併發請求經過負載均衡server，分配到內網的多臺Webserver，它們首先向存儲發送查詢請求，而後，在某個請求成功寫入參與記錄的時間差內。其它的請求獲查詢到的結果都是「沒有參與記錄」。這裏，就存在邏輯推斷被繞過的風險。

應對方案：

在程序入口處。一個帳號僅僅贊成接受1個請求，其它請求過濾。

不只攻克了同一個帳號。發送N個請求的問題，還保證了興許的邏輯流程的安全。實現方案。可以經過Redis這樣的內存緩存服務，寫入一個標誌位（僅僅贊成1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加。

或者，本身實現一個服務。將同一個帳號的請求放入一個隊列中，處理完一個，再處理下一個。

6.2 多個帳號，一次性發送多個請求

很是多公司的帳號註冊功能，在發展早期差點兒是沒有限制的。很是easy就可以註冊很是多個帳號。

所以，也致使了出現了一些特殊的工做室，經過編寫本身主動註冊腳本，積累了一大批「殭屍帳號」，數量龐大。幾萬甚至幾十萬的帳號不等，專門作各類刷的行爲（這就是微博中的「殭屍粉「的來源）。

舉個樣例。好比微博中有轉發抽獎的活動，假設咱們使用幾萬個「殭屍號」去混進去轉發，這樣就可以大大提高咱們中獎的機率。

這樣的帳號，使用在秒殺和搶購裏。也是同一個道理。好比。iPhone官網的搶購，火車票黃牛黨。

應對方案：

這樣的場景，可以經過檢測指定機器IP請求頻率就可以解決，假設發現某個IP請求頻率很是高，可以給它彈出一個驗證碼或者直接禁止它的請求：

1. 彈出驗證碼。最核心的追求，就是分辨出真有用戶。所以。你們可能常常發現。站點彈出的驗證碼，有些是「鬼神亂舞」的樣子，有時讓咱們根本沒法看清。他們這樣作的緣由，事實上也是爲了讓驗證碼的圖片不被輕易識別，由於強大的「本身主動腳本」可以經過圖片識別裏面的字符。而後讓腳本本身主動填寫驗證碼。實際上。有一些很是創新的驗證碼，效果會比較好，好比給你一個簡單問題讓你回答，或者讓你完畢某些簡單操做（好比百度貼吧的驗證碼）。
2. 直接禁止IP。其實是有些粗暴的。由於有些真有用戶的網絡場景剛好是同一出口IP的，可能會有「誤傷「。

   但是這一個作法簡單高效，依據實際場景使用可以得到很是好的效果。

6.3 多個帳號。不一樣IP發送不一樣請求

所謂道高一尺，魔高一丈。有進攻，就會有防守，永不休止。這些「工做室」。發現你對單機IP請求頻率有控制以後。他們也針對這樣的場景，想出了他們的「新進攻方案」，就是不斷改變IP。

有同窗會好奇，這些隨機IP服務怎麼來的。有一些是某些機構本身佔領一批獨立IP，而後作成一個隨機代理IP的服務，有償提供給這些「工做室」使用。

另外一些更爲黑暗一點的。就是經過木馬黑掉普通用戶的電腦，這個木馬也不破壞用戶電腦的正常運做。僅僅作一件事情，就是轉發IP包，普通用戶的電腦被變成了IP代理出口。

經過這樣的作法。黑客就拿到了大量的獨立IP，而後搭建爲隨機IP服務。就是爲了掙錢。

應對方案：

說實話，這樣的場景下的請求，和真有用戶的行爲。已經基本一樣了，想作分辨很是困難。

再作進一步的限制很是easy「誤傷「真有用戶，這個時候。一般僅僅能經過設置業務門檻高來限制這樣的請求了，或者經過帳號行爲的」數據挖掘「來提早清理掉它們。

殭屍帳號也仍是有一些共同特徵的，好比帳號很是可能屬於同一個號碼段甚至是連號的，活躍度不高，等級低，資料不全等等。

依據這些特色。適當設置參與門檻，好比限制參與秒殺的帳號等級。經過這些業務手段，也是可以過濾掉一些殭屍號。

7 高併發下的數據安全

咱們知道在多線程寫入同一個文件的時候，會存現「線程安全」的問題（多個線程同一時候執行同一段代碼，假設每次執行結果和單線程執行的結果是同樣的，結果和預期一樣，就是線程安全的）。假設是MySQL數據庫，可以使用它自帶的鎖機制很是好的解決這個問題，但是，在大規模併發的場景中。是不推薦使用MySQL的。秒殺和搶購的場景中，還有另一個問題，就是「超發」，假設在這方面控制不慎，會產生髮送過多的狀況。咱們也之前據說過。某些電商搞搶購活動，買家成功拍下後。商家卻不認可訂單有效。拒絕發貨。

這裏的問題，或許並不必定是商家奸詐，而是系統技術層面存在超發風險致使的。

7.1 超發的緣由

假設某個搶購場景中，咱們一共僅僅有100個商品，在最後一刻。咱們已經消耗了99個商品。僅剩最後一個。

這個時候，系統發來多個併發請求，這批請求讀取到的商品餘量都是99個，而後都經過了這一個餘量推斷。終於致使超發。

在上面的這個圖中。就致使了併發用戶B也「搶購成功」。多讓一我的得到了商品。這樣的場景，在高併發的狀況下很是easy出現。

7.2 悲觀鎖思路

解決線程安全的思路很是多，可以從「悲觀鎖」的方向開始討論。

悲觀鎖，也就是在改動數據的時候。採用鎖定狀態，排斥外部請求的改動。遇到加鎖的狀態。就必須等待。

儘管上述的方案的確攻克了線程安全的問題，但是。別忘記，咱們的場景是「高併發」。也就是說，會很是多這樣的改動請求，每一個請求都需要等待「鎖」。某些線程可能永遠都沒有機會搶到這個「鎖」，這樣的請求就會死在那裏。同一時候，這樣的請求會很是多。瞬間增大系統的平均響應時間，結果是可用鏈接數被耗盡，系統陷入異常。

7.3 FIFO隊列思路

那好。那麼咱們略微改動一下上面的場景。咱們直接將請求放入隊列中的，採用FIFO（First Input First Output。先進先出），這樣的話，咱們就不會致使某些請求永遠獲取不到鎖。

看到這裏，是否是有點強行將多線程變成單線程的感受哈。

而後。咱們現在攻克了鎖的問題。所有請求採用「先進先出」的隊列方式來處理。

那麼新的問題來了。高併發的場景下，由於請求很是多，很是可能一瞬間將隊列內存「撐爆」。而後系統又陷入到了異常狀態。

或者設計一個極大的內存隊列。也是一種方案，但是。系統處理完一個隊列內請求的速度根本沒法和瘋狂涌入隊列中的數目相比。也就是說，隊列內的請求會越積累越多，終於Web系統平均響應時候仍是會大幅降低。系統仍是陷入異常。

7.4 樂觀鎖思路

這個時候，咱們就可以討論一下「樂觀鎖」的思路了。

樂觀鎖。是相對於「悲觀鎖」採用更爲寬鬆的加鎖機制，大都是採用帶版本（Version）更新。

實現就是，這個數據所有請求都有資格去改動，但會得到一個該數據的版本，僅僅有版本符合的才幹更新成功，其它的返回搶購失敗。

這樣的話。咱們就不需要考慮隊列的問題，只是，它會增大CPU的計算開銷。

但是，綜合來講。這是一個比較好的解決方式。

有很是多軟件和服務都「樂觀鎖」功能的支持。好比Redis中的watch就是當中之中的一個。經過這個實現，咱們保證了數據的安全。

8 總結

互聯網正在快速發展，使用互聯網服務的用戶越多，高併發的場景也變得愈來愈多。

電商秒殺和搶購，是兩個比較典型的互聯網高併發場景。儘管咱們解決這個問題的具體技術方案可能千差萬別，但是遇到的挑戰倒是相似的，所以解決這個問題的思路也殊途同歸。

來源：http://blog.jobbole.com/96984/