1. 正常電子商務(wù)流程

（1）查詢商品； 
（2）創(chuàng)建訂單； 
（3）扣減庫存； 
（4）更新訂單； 
（5）付款； 
（6）賣家發(fā)貨；

2. 秒殺業(yè)務(wù)的特性

（1）低廉價格； 
（2）大幅推廣； 
（3）瞬時售空； 
（4）一般是定時上架； 
（5）時間短、瞬時并發(fā)量高；

2 秒殺技術(shù)挑戰(zhàn)

1. 對現(xiàn)有網(wǎng)站業(yè)務(wù)造成沖擊

解決方案 ：將秒殺系統(tǒng)獨立部署，甚至 使用獨立域名，使其與網(wǎng)站完全隔離 。

2. 高并發(fā)下的應(yīng)用、數(shù)據(jù)庫負(fù)載

解決方案 ：重新設(shè)計秒殺商品頁面，不使用網(wǎng)站原來的商品詳細(xì)頁面， 頁面內(nèi)容靜態(tài)化，用戶請求不需要經(jīng)過應(yīng)用服務(wù) 。

3. 突然增加的網(wǎng)絡(luò)及服務(wù)器帶寬

解決方案 ：因為秒殺新增的網(wǎng)絡(luò)帶寬，必須和運營商重新購買或者租借。為了減輕網(wǎng)站服務(wù)器的壓力，
需要將秒殺商品頁面緩存在CDN，同樣需要和CDN服務(wù)商臨時租借新增的出口帶寬 。

4. 直接下單

解決方案 ：為了避免用戶直接訪問下單頁面URL，需要將改URL動態(tài)化，即使秒殺系統(tǒng)的開發(fā)者也無法在秒殺開始前訪問下單頁面的URL。辦法是在
下單頁面URL加入由服務(wù)器端生成的隨機數(shù)作為參數(shù)，在秒殺開始的時候才能得到 。

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

解決方案 ：使用JavaScript腳本控制，
在秒殺商品靜態(tài)頁面中加入一個JavaScript文件引用，該JavaScript文件中包含秒殺開始標(biāo)志為否
；當(dāng)秒殺開始的時候生成一個新的JavaScript文件（ 文件名保持不變，只是內(nèi)容不一樣 ），更新秒殺開始標(biāo)志為是，
加入下單頁面的URL及隨機數(shù)參數(shù)（這個隨機數(shù)只會產(chǎn)生一個，即所有人看到的URL都是同一個，服務(wù)器端可以用redis這種分布式緩存服務(wù)器來保存隨機數(shù)）
，并被用戶瀏覽器加載，控制秒殺商品頁面的展示。
這個JavaScript文件的加載可以加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理服務(wù)器緩存 。

這個JavaScript文件非常小，即使每次瀏覽器刷新都訪問JavaScript文件服務(wù)器也不會對服務(wù)器集群和網(wǎng)絡(luò)帶寬造成太大壓力。

6. 如何只允許第一個提交的訂單被發(fā)送到訂單子系統(tǒng)

解決方案
：假設(shè)下單服務(wù)器集群有10臺服務(wù)器，每臺服務(wù)器只接受最多10個下單請求。在還沒有人提交訂單成功之前，如果一臺服務(wù)器已經(jīng)有十單了，而有的一單都沒處理，可能出現(xiàn)的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結(jié)束頁面，再刷新一下頁面，有可能被一單都沒有處理的服務(wù)器處理，進入了填寫訂單的頁面，
可以考慮通過cookie的方式來應(yīng)對，符合一致性原則 。當(dāng)然可以 采用最少連接的負(fù)載均衡算法 ，出現(xiàn)上述情況的概率大大降低。

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

• 下單服務(wù)器檢查本機已處理的下單請求數(shù)目：

如果超過10條，直接返回已結(jié)束頁面給用戶；

如果未超過10條，則用戶可進入填寫訂單及確認(rèn)頁面；

• 檢查全局已提交訂單數(shù)目：

已超過秒殺商品總數(shù)，返回已結(jié)束頁面給用戶；

未超過秒殺商品總數(shù)，提交到子訂單系統(tǒng)；

8. 秒殺一般是定時上架

9. 減庫存的操作

10. 庫存會帶來“超賣”的問題：售出數(shù)量多于庫存數(shù)量

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

    update auction_auctions set 
    quantity = quantity-#count# 
    where auction_id = #itemId# and quantity >= #count# 

11. 秒殺器的應(yīng)對

3 秒殺架構(gòu)原則

1. 盡量將請求攔截在系統(tǒng)上游

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

4 秒殺架構(gòu)設(shè)計

第一個階段是秒殺開始前某個時間到秒殺開始， 這個階段可以稱之為 準(zhǔn)備階段，用戶在準(zhǔn)備階段等待秒殺 ；

第二個階段就是秒殺開始到所有參與秒殺的用戶獲得秒殺結(jié)果， 這個就稱為 秒殺階段 吧。

4.1 前端層設(shè)計

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

2. 第二個是倒計時

3. 瀏覽器層請求攔截

（1） 產(chǎn)品層面 ，用戶點擊“查詢”或者“購票”后，按鈕置灰，禁止用戶重復(fù)提交請求;

（2） JS層面 ，限制用戶在x秒之內(nèi)只能提交一次請求;

4.2 站點層設(shè)計

（1） 同一個uid，限制訪問頻度 ，做頁面緩存，x秒內(nèi)到達(dá)站點層的請求，均返回同一頁面

（2） 同一個item的查詢，例如手機車次 ，做頁面緩存，x秒內(nèi)到達(dá)站點層的請求，均返回同一頁面

4.3 服務(wù)層設(shè)計

（1）大哥，我是服務(wù)層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去數(shù)據(jù)庫有什么意義呢？
對于寫請求，做請求隊列，每次只透過有限的寫請求去數(shù)據(jù)層，如果均成功再放下一批，如果庫存不夠則隊列里的寫請求全部返回“已售完” ；

（2） 對于讀請求，還用說么？cache來抗 ，不管是memcached還是redis，單機抗個每秒10w應(yīng)該都是沒什么問題的；

1. 用戶請求分發(fā)模塊 ：使用Nginx或Apache將用戶的請求分發(fā)到不同的機器上。
2. 用戶請求預(yù)處理模塊 ：判斷商品是不是還有剩余來決定是不是要處理該請求。
3. 用戶請求處理模塊 ：把通過預(yù)處理的請求封裝成事務(wù)提交給數(shù)據(jù)庫，并返回是否成功。
4. 數(shù)據(jù)庫接口模塊 ：該模塊是數(shù)據(jù)庫的唯一接口，負(fù)責(zé)與數(shù)據(jù)庫交互，提供RPC接口供查詢是否秒殺結(jié)束、剩余數(shù)量等信息。

1. 用戶請求預(yù)處理模塊

    package seckill;
    import org.apache.http.HttpRequest;
    /**
        * 預(yù)處理階段，把不必要的請求直接駁回，必要的請求添加到隊列中進入下一階段.
        */
    public class PreProcessor {
          // 商品是否還有剩余
          private static boolean reminds = true;
          private static void forbidden() {
              // Do something.
          }
          public static boolean checkReminds() {
              if (reminds) {
                  // 遠(yuǎn)程檢測是否還有剩余，該RPC接口應(yīng)由數(shù)據(jù)庫服務(wù)器提供，不必完全嚴(yán)格檢查.
                  if (!RPC.checkReminds()) {
                      reminds = false;
                  }
              }
              return reminds;
          }
        /**
         * 每一個HTTP請求都要經(jīng)過該預(yù)處理.
         */
          public static void preProcess(HttpRequest request) {
              if (checkReminds()) {
                  // 一個并發(fā)的隊列
                  RequestQueue.queue.add(request);
              } else {
                  // 如果已經(jīng)沒有商品了，則直接駁回請求即可.
                  forbidden();
              }
          }
    }

• 并發(fā)隊列的選擇

ArrayBlockingQueue是 初始容量固定的阻塞隊列
，我們可以用來作為數(shù)據(jù)庫模塊成功競拍的隊列，比如有10個商品，那么我們就設(shè)定一個10大小的數(shù)組隊列。

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

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

    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>();
    }

2. 用戶請求模塊

    package seckill;
    import org.apache.http.HttpRequest;
    public class Processor {
        /**
         * 發(fā)送秒殺事務(wù)到數(shù)據(jù)庫隊列.
         */
        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.
        }
    }

3. 數(shù)據(jù)庫模塊  
   數(shù)據(jù)庫主要是使用一個ArrayBlockingQueue來暫存有可能成功的用戶請求。

    package seckill;
    import java.util.concurrent.ArrayBlockingQueue;
    /**
        * DB應(yīng)該是數(shù)據(jù)庫的唯一接口.
        */
    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 = ?
                  // 如果數(shù)據(jù)庫商品數(shù)量大約總數(shù)，則標(biāo)志秒殺已完成，設(shè)置標(biāo)志位reminds = false.
                  info = bids.poll();
              }
          }
    }

4.4 數(shù)據(jù)庫設(shè)計

4.4.1 基本概念

1. 范圍：range

優(yōu)點：簡單，容易擴展

缺點：各庫壓力不均（新號段更活躍）

2. 哈希：hash 【大部分互聯(lián)網(wǎng)公司采用的方案二：哈希分庫，哈希路由】

優(yōu)點：簡單，數(shù)據(jù)均衡，負(fù)載均勻

缺點：遷移麻煩（2庫擴3庫數(shù)據(jù)要遷移）

3. 路由服務(wù)：router-config-server

優(yōu)點：靈活性強，業(yè)務(wù)與路由算法解耦

缺點：每次訪問數(shù)據(jù)庫前多一次查詢

4.4.2 設(shè)計思路

1. 如何保證數(shù)據(jù)可用性；
2. 如何提高數(shù)據(jù)庫讀性能（大部分應(yīng)用讀多寫少，讀會先成為瓶頸）；
3. 如何保證一致性；
4. 如何提高擴展性；

1. 如何保證數(shù)據(jù)的可用性？

如何保證站點的可用性？復(fù)制站點，冗余站點

如何保證服務(wù)的可用性？復(fù)制服務(wù)，冗余服務(wù)

如何保證數(shù)據(jù)的可用性？復(fù)制數(shù)據(jù)，冗余數(shù)據(jù)

2. 如何保證數(shù)據(jù)庫“讀”高可用？

3. 如何保證數(shù)據(jù)庫“寫”高可用？

1. 兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id為0,2,4,6…；2寫庫的id為1,3,5,7…；
2. 不使用數(shù)據(jù)的id，業(yè)務(wù)層自己生成唯一的id，保證數(shù)據(jù)不沖突；

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

1. 不能通過加從庫的方式擴展讀性能；
2. 資源利用率為50%，一臺冗余主沒有提供服務(wù)；

4. 如何擴展讀性能

寫庫 不建立索引；

線上讀庫 建立線上訪問索引，例如uid；

線下讀庫 建立線下訪問索引，例如time；

1. 從庫越多，同步越慢；
2. 同步越慢，數(shù)據(jù)不一致窗口越大（不一致后面說，還是先說讀性能的提高）；

不管采用主從的方式擴展讀性能，還是緩存的方式擴展讀性能，數(shù)據(jù)都要復(fù)制多份（主+從，db+cache），一定會引發(fā)一致性問題。

5. 如何保證一致性？

1. 中間件

2. 強制讀主

（1）淘汰cache；

（2）寫數(shù)據(jù)庫；

（1）讀cache，如果cache hit則返回；

（2）如果cache miss，則讀從庫；

（3）讀從庫后，將數(shù)據(jù)放回cache；

（1）淘汰cache；

（2）寫數(shù)據(jù)庫；

（3）在經(jīng)過“主從同步延時窗口時間”后，再次發(fā)起一個異步淘汰cache的請求；

3. 如何提高數(shù)據(jù)庫的擴展性？

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

第二步 ，修改配置，2庫變4庫（原來MOD2，現(xiàn)在配置修改后MOD4），擴容完成；

1. 將舊的雙主同步解除；
2. 增加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務(wù)）；
3. 刪除多余的數(shù)據(jù)（余0的主，可以將余2的數(shù)據(jù)刪除掉）；

5 大并發(fā)帶來的挑戰(zhàn)

5.1 請求接口的合理設(shè)計

5.2 高并發(fā)的挑戰(zhàn)：一定要“快”

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

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

5.3 重啟與過載保護

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

6.1 同一個賬號，一次性發(fā)出多個請求

6.2 多個賬號，一次性發(fā)送多個請求

1. 彈出驗證碼，最核心的追求，就是分辨出真實用戶。
   因此，大家可能經(jīng)常發(fā)現(xiàn)，網(wǎng)站彈出的驗證碼，有些是“鬼神亂舞”的樣子，有時讓我們根本無法看清。他們這樣做的原因，其實也是為了讓驗證碼的圖片不被輕易識別，因為強大的“自動腳本”可以通過圖片識別里面的字符，然后讓腳本自動填寫驗證碼。實際上，有一些非常創(chuàng)新的驗證碼，效果會比較好，例如給你一個簡單問題讓你回答，或者讓你完成某些簡單操作（例如百度貼吧的驗證碼）。
2. 直接禁止IP，實際上是有些粗暴的，因為有些真實用戶的網(wǎng)絡(luò)場景恰好是同一出口IP的，可能會有“誤傷“
   。但是這一個做法簡單高效，根據(jù)實際場景使用可以獲得很好的效果。

6.3 多個賬號，不同IP發(fā)送不同請求

7 高并發(fā)下的數(shù)據(jù)安全

7.1 超發(fā)的原因

7.2 悲觀鎖思路

悲觀鎖，也就是在修改數(shù)據(jù)的時候，采用鎖定狀態(tài)，排斥外部請求的修改。遇到加鎖的狀態(tài)，就必須等待。

7.3 FIFO隊列思路

7.4 樂觀鎖思路

8 總結(jié)