-     前言     -

秒殺系統(tǒng)相信很多人見過，比如京東或者淘寶的秒殺，小米手機的秒殺，那么秒殺系統(tǒng)的后臺是如何實現的呢？我們如何設計一個秒殺系統(tǒng)呢？對于秒殺系統(tǒng)應該考慮哪些問題？如何設計出健壯的秒殺系統(tǒng)？本文我們就來探討一下這個問題。

-     秒殺應該考慮哪些問題     -

-     秒殺系統(tǒng)的設計和技術方案     -

1、秒殺系統(tǒng)數據庫設計 針對「數據庫設計」提出的秒殺數據庫的問題，因此應該單獨設計一個秒殺數據庫，防止因為秒殺活動的高并發(fā)訪問拖垮整個網站。這里只需要兩張表，一張是秒殺訂單表，一張是秒殺貨品表。

其實應該還有幾張表，商品表：可以關聯 goods_id 查到具體的商品信息，商品圖像、名稱、平時價格、秒殺價格等，還有用戶表：根據用戶 user_id 可以查詢到用戶昵稱、用戶手機號，收貨地址等其他額外信息，這個具體就不給出實例了。
2、秒殺 url 的設計 為了避免有程序訪問經驗的人通過下單頁面url直接訪問后臺接口來秒殺貨品，我們需要將秒殺的 url 實現動態(tài)化，即使是開發(fā)整個系統(tǒng)的人都無法在秒殺開始前知道秒殺的 url。具體的做法就是通過md5加密一串隨機字符作為秒殺的 url，然后前端訪問后臺獲取具體的 url，后臺校驗通過之后才可以繼續(xù)秒殺。
3、秒殺頁面靜態(tài)化 將商品的描述、參數、成交記錄、圖像、評價等全部寫入到一個靜態(tài)頁面，用戶請求不需要通過訪問后端服務器，不需要經過數據庫，直接在前臺客戶端生成，這樣可以最大可能的減少服務器的壓力。具體的方法可以使用 freemarker 模板技術，建立網頁模板，填充數據，然后渲染網頁。
4、單體 Redis 升級為集群 Redis 秒殺是一個讀多寫少的場景，使用Redis做緩存再合適不過。不過考慮到緩存擊穿問題，我們應該構建 Redis 集群，采用哨兵模式，可以提升 Redis 的性能和可用性。
5、使用 Nginx Nginx 是一個高性能 Web 服務器，它的并發(fā)能力可以達到幾萬，而 Tomcat 只有幾百。通過 Nginx 映射客戶端請求，再分發(fā)到后臺 Tomcat 服務器集群中可以大大提升并發(fā)能力。
6、精簡SQL 典型的一個場景是在進行扣減庫存的時候，傳統(tǒng)的做法是先查詢庫存，再去 update。這樣的話需要兩個 SQL，而實際上一個 SQL 我們就可以完成的。可以用這樣的做法：update miaosha_goods set stock =stock-1 where goos_id ={#goods_id} and version = #{version} and sock>0;這樣的話，就可以保證庫存不會超賣并且一次更新庫存，還有注意一點這里使用了版本號的樂觀鎖，相比較悲觀鎖，它的性能較好。
7、Redis 預減庫存 很多請求進來，都需要后臺查詢庫存,這是一個頻繁讀的場景?？梢允褂?Redis 來預減庫存，在秒殺開始前可以在 Redis 設值，比如 redis.set(goodsId,100)，這里預放的庫存為 100 可以設值為常量，每次下單成功之后，Integer stock = (Integer)redis.get(goosId); 然后判斷 sock 的值，如果小于常量值就減去 1；不過注意當取消的時候，需要增加庫存，增加庫存的時候也得注意不能大于之間設定的總庫存數（查詢庫存和扣減庫存需要原子操作，此時可以借助lua腳本）下次下單再獲取庫存的時候，直接從 Redis 里面查就可以了。
8、接口限流 秒殺最終的本質是數據庫的更新，但是有很多大量無效的請求，我們最終要做的就是如何把這些無效的請求過濾掉，防止?jié)B透到數據庫。限流的話，需要入手的方面很多：
（1）前端限流 首先第一步就是通過前端限流，用戶在秒殺按鈕點擊以后發(fā)起請求，那么在接下來的5秒是無法點擊（通過設置按鈕為 disable）。這一小舉措開發(fā)起來成本很小，但是很有效。
（2）同一個用戶 xx 秒內重復請求直接拒絕 具體多少秒需要根據實際業(yè)務和秒殺的人數而定，一般限定為 10 秒。具體的做法就是通過 Redis 的鍵過期策略，首先對每個請求都從 String value = redis.get(userId);如果獲取到這個 value 為空或者為 null，表示它是有效的請求，然后放行這個請求。如果不為空表示它是重復性請求，直接丟掉這個請求。如果有效，采用 redis.setexpire(userId,value,10).value 可以是任意值，一般放業(yè)務屬性比較好，這個是設置以 userId 為 key，10 秒的過期時間（10秒后，key對應的值自動為null）。
（3）令牌桶算法限流 接口限流的策略有很多，我們這里采用令牌桶算法。令牌桶算法的基本思路是每個請求嘗試獲取一個令牌，后端只處理持有令牌的請求，生產令牌的速度和效率我們都可以自己限定，Guava 提供了 RateLimter 的 API 供我們使用。以下做一個簡單的例子，注意需要引入 Guava：

public class TestRateLimiter {

    public static void main(String[] args) {
        //1秒產生1個令牌
        final RateLimiter rateLimiter = RateLimiter.create(1); for (int i = 0; i < 10; i++) { //該方法會阻塞線程，直到令牌桶中能取到令牌為止才繼續(xù)向下執(zhí)行。 double waitTime= rateLimiter.acquire(); System.out.println("任務執(zhí)行" + i + "等待時間" + waitTime);
        }
        System.out.println("執(zhí)行結束");
    }
}

上面代碼的思路就是通過 RateLimiter 來限定我們的令牌桶每秒產生 1 個令牌（生產的效率比較低），循環(huán) 10 次去執(zhí)行任務。acquire 會阻塞當前線程直到獲取到令牌，也就是如果任務沒有獲取到令牌，會一直等待。那么請求就會卡在我們限定的時間內才可以繼續(xù)往下走，這個方法返回的是線程具體等待的時間。執(zhí)行如下：

可以看到任務執(zhí)行的過程中，第1個是無需等待的，因為已經在開始的第 1 秒生產出了令牌。接下來的任務請求就必須等到令牌桶產生了令牌才可以繼續(xù)往下執(zhí)行。如果沒有獲取到就會阻塞（有一個停頓的過程）。不過這個方式不太好，因為用戶如果在客戶端請求，如果較多的話，直接后臺在生產 token 就會卡頓（用戶體驗較差），它是不會拋棄任務的，我們需要一個更優(yōu)秀的策略：如果超過某個時間沒有獲取到，直接拒絕該任務。接下來再來個案例：

public class TestRateLimiter2 {

    public static void main(String[] args) {
        final RateLimiter rateLimiter = RateLimiter.create(1); for (int i = 0; i < 10; i++) { long timeOut = (long) 0.5; boolean isValid = rateLimiter.tryAcquire(timeOut, TimeUnit.SECONDS); System.out.println("任務" + i + "執(zhí)行是否有效:" + isValid); if (!isValid) { continue;
            }
            System.out.println("任務" + i + "在執(zhí)行");
        }
        System.out.println("結束");
    }
}

其中用到了 tryAcquire 方法，這個方法的主要作用是設定一個超時的時間，如果在指定的時間內預估（注意是預估并不會真實的等待），如果能拿到令牌就返回 true，如果拿不到就返回 false。然后我們讓無效的直接跳過，這里設定每秒生產1個令牌，讓每個任務嘗試在 0.5 秒獲取令牌，如果獲取不到，就直接跳過這個任務（放在秒殺環(huán)境里就是直接拋棄這個請求）。程序實際運行如下：

只有第 1 個獲取到了令牌，順利執(zhí)行了，下面的基本都直接拋棄了，因為 0.5 秒內，令牌桶（1秒1個）來不及生產就肯定獲取不到返回false了。
這個限流策略的效率有多高呢？假如我們的并發(fā)請求是 400 萬瞬間的請求，將令牌產生的效率設為每秒 20 個，每次嘗試獲取令牌的時間是 0.05 秒，那么最終測試下來的結果是，每次只會放行 4 個左右的請求,大量的請求會被拒絕，這就是令牌桶算法的優(yōu)秀之處。
9、異步下單 為了提升下單的效率，并且防止下單服務的失敗。需要將下單這一操作進行異步處理。最常采用的辦法是使用隊列，隊列最顯著的三個優(yōu)點：異步、削峰、解耦。這里可以采用 RabbitMQ，在后臺經過了限流、庫存校驗之后，流入到這一步驟的就是有效請求。然后發(fā)送到隊列里，隊列接受消息，異步下單。下完單，入庫沒有問題可以用短信通知用戶秒殺成功。假如失敗的話，可以采用補償機制，重試。
10、服務降級 假如在秒殺過程中出現了某個服務器宕機，或者服務不可用，應該做好后備工作。之前的博客里有介紹通過 Hystrix 進行服務熔斷和降級，可以開發(fā)一個備用服務，假如服務器真的宕機了，直接給用戶一個友好的提示返回，而不是直接卡死，服務器錯誤等生硬的反饋。

-     總結     -

秒殺流程圖：

這就是我設計出來的秒殺流程圖，當然不同的秒殺體量針對的技術選型都不一樣，這個流程可以支撐起幾十萬的流量，如果是成千萬破億那就得重新設計了。
比如數據庫的分庫分表、隊列改成用 Kafka、Redis 增加集群數量等手段。通過本次設計主要是要表明的是我們如何應對高并發(fā)的處理，并開始嘗試解決它，在工作中多思考、多動手能提升我們的能力水平，加油！如果本篇博客有任何錯誤，請麻煩指出來，不勝感激。