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

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

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

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

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

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

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

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

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

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

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

4. 直接下單

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

5. 如何控制秒殺商品頁(yè)面購(gòu)買按鈕的點(diǎn)亮

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

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

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

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

7. 如何進(jìn)行下單前置檢查

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

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

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

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

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

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

8. 秒殺一般是定時(shí)上架

9. 減庫(kù)存的操作

10. 庫(kù)存會(huì)帶來(lái)“超賣”的問(wèn)題：售出數(shù)量多于庫(kù)存數(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)對(duì)

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

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

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

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

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

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

4.1 前端層設(shè)計(jì)

1. 第一個(gè)是秒殺頁(yè)面的展示

2. 第二個(gè)是倒計(jì)時(shí)

3. 瀏覽器層請(qǐng)求攔截

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

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

4.2 站點(diǎn)層設(shè)計(jì)

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

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

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

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

（2） 對(duì)于讀請(qǐng)求，還用說(shuō)么？cache來(lái)抗 ，不管是memcached還是redis，單機(jī)抗個(gè)每秒10w應(yīng)該都是沒什么問(wèn)題的；

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

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

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

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

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

ConcurrentLinkedQueue使用的是 CAS原語(yǔ)無(wú)鎖隊(duì)列實(shí)現(xiàn)，是一個(gè)異步隊(duì)列 ，入隊(duì)的速度很快，出隊(duì)進(jìn)行了加鎖，性能稍慢。

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

    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. 用戶請(qǐng)求模塊

    package seckill;
    import org.apache.http.HttpRequest;
    public class Processor {
        /**
         * 發(fā)送秒殺事務(wù)到數(shù)據(jù)庫(kù)隊(duì)列.
         */
        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ù)庫(kù)模塊  
   數(shù)據(jù)庫(kù)主要是使用一個(gè)ArrayBlockingQueue來(lái)暫存有可能成功的用戶請(qǐng)求。

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

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

4.4.1 基本概念

1. 范圍：range

優(yōu)點(diǎn)：簡(jiǎn)單，容易擴(kuò)展

缺點(diǎn)：各庫(kù)壓力不均（新號(hào)段更活躍）

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

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

缺點(diǎn)：遷移麻煩（2庫(kù)擴(kuò)3庫(kù)數(shù)據(jù)要遷移）

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

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

缺點(diǎn)：每次訪問(wèn)數(shù)據(jù)庫(kù)前多一次查詢

4.4.2 設(shè)計(jì)思路

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

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

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

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

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

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

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

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

1. 讀寫沒有延時(shí)；
2. 讀寫高可用；

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

4. 如何擴(kuò)展讀性能

寫庫(kù) 不建立索引；

線上讀庫(kù) 建立線上訪問(wèn)索引，例如uid；

線下讀庫(kù) 建立線下訪問(wèn)索引，例如time；

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

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

5. 如何保證一致性？

1. 中間件

2. 強(qiáng)制讀主

（1）淘汰cache；

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

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

（2）如果cache miss，則讀從庫(kù)；

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

（1）淘汰cache；

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

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

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

第一步 ，將一個(gè)主庫(kù)提升;

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

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

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

5.1 請(qǐng)求接口的合理設(shè)計(jì)

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

    20*500/0.1 = 100000 （10萬(wàn)QPS）

    20*500/0.25 = 40000 （4萬(wàn)QPS）

5.3 重啟與過(guò)載保護(hù)

6 作弊的手段：進(jìn)攻與防守

6.1 同一個(gè)賬號(hào)，一次性發(fā)出多個(gè)請(qǐng)求

6.2 多個(gè)賬號(hào)，一次性發(fā)送多個(gè)請(qǐng)求

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

6.3 多個(gè)賬號(hào)，不同IP發(fā)送不同請(qǐng)求

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

7.1 超發(fā)的原因

7.2 悲觀鎖思路

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

7.3 FIFO隊(duì)列思路

7.4 樂(lè)觀鎖思路

8 總結(jié)

- EOF -