服務介紹

限時搶購又稱閃購，英文Flash sale，起源于法國網站Vente Privée。閃購模式即是以互聯網為媒介的B2C電子零售交易活動，以限時特賣的形式，定期定時推出國際知名品牌的商品，一般以原價1-5折的價格供專屬會員限時搶購，每次特賣時間持續5-10天不等，先到先買，限時限量，售完即止。顧客在指定時間內(一般為20分鐘)必須付款，否則商品會重新放到待銷售商品的行列里。

模式特征：

品牌豐富 —— 推出國內外一二線名牌商品，供消費者購買選擇;

時間短暫 —— 每個品牌推出時間短暫，一般為5—10天，先到先買，限量售賣，售完即止;

折扣超低 —— 以商品原價1—5折的價格銷售，折扣力度大。

摘自【百度百科】，通過這段簡介相信對限時搶購有了一定的了解，我們內部稱之為搶購系統。

對于搶購系統來說，首先要有可搶購的活動，而且這些活動具有促銷性質，比如直降500元。其次要求可搶購的活動類目豐富，用戶才有充分的選擇性。618(6.1-6.20)期間增量促銷活動量非常多，可能某個活動力度特別大，大多用戶都在搶，必然對系統是一個考驗。這樣搶購系統具有秒殺特性，并發訪問量高，同時用戶也可選購多個限時搶商品，與普通商品一起進購物車結算。這種大型活動的負載可能是平時的幾十倍，所以通過增加硬件、優化瓶頸代碼等手段是很難達到目標的，所以搶購系統得專門設計。

服務主要功能

創建促銷服務：采銷創建促銷后，促銷管理系統審核通過后，會調用搶購系統創建促銷;

搶服務：為符合條件的訂單操作剩余數，主要是扣減剩余數;

針對哪些SKU

目前主要為單品促銷，直降或者一口價，比如：

主要渠道

移動APP、微信、手Q和主站

限購類型

限數量、限ip、限pin和限制ip與pin

系統設計要點

如何實現實時庫存?

這里說的庫存不是真正意義上的庫存，其實是該促銷可以搶購的數量，真正的庫存在基礎庫存服務。用戶點擊『提交訂單』按鈕后，在搶購系統中獲取了資格后才去基礎庫存服務中扣減真正的庫存;而搶購系統控制的就是資格/剩余數。傳統方案利用數據庫行鎖，但是在促銷高峰數據庫壓力過大導致服務不可用，目前采用redis集群(16分片)緩存促銷信息，例如促銷id、促銷剩余數、搶次數等，搶的過程中按照促銷id散列到對應分片，實時扣減剩余數。當剩余數為0或促銷刪除，價格恢復原價。

如何設計搶購redis數據結構?

采銷人員發布促銷后，在搶購redis中生成一筆記錄，給搶服務提供基本信息。每一個促銷對應一個促銷id，促銷信息是Hashes結構。

例如促銷A，對應的類型為單品促銷，我們暫且認為類型值為1，對應redis中的key為 C_A_1，數據結構內容類似于如下：

o: 100 // 原始數量  
b: 99 // 可搶購數量，假如搶購了一個剩下了99  
c: 1 // 搶購次數記錄，用來限流，后面會介紹到 

如何保證不超賣?

因為扣減資格是一組操作，我們利用EVAL操作redis剩余數實現原子化操作，偽代碼如下：

local key = KEYS[1] 
local tag  = "b" 
local num   = tonumber(ARGV[1]); 
local lastNum = redis.call('HINCRBY',key,tag,-num); 
if業務性判斷ortonumber(lastNum) == 0then 
   return lastNum 
end 

如上代碼會返回剩余數，如果小于等于0了，則沒有庫存了。

如何提高吞吐量?

減少網絡交互(一次搶數據通過 EVALSHA 一次性提交給redis集群);數據庫操作異步化(使用JMQ異步記錄日志)。

如何保證可用性?

采用JSF(京東內部SOA框架)對外開放服務(搶服務和發布促銷服務)，可降級為系統自身webservice服務;

搶購系統主要依賴于redis集群，redis采用一主三從集群方案，部署在兩個機房，每個集群16個分片，每兩分片共用一臺物理機，可通過配置中心切換主從;

如果Redis掛掉了，如何恢復呢?通過匯總MySQL中的搶購和取消流水日志，并恢復Redis的搶購數量。

系統架構

這里主要涉及搶服務架構剖析，因為它具有典型的高并發特性，下面是基本架構概圖：

注：此處的庫存是可搶購數量設置，或者叫做資格/剩余數，并非真正的實際庫存。

搶服務流程

Redis使用單個Lua解釋器去運行所有腳本，并且Redis 也保證腳本會以原子性(atomic)的方式執行：當某個腳本正在運行的時候，不會有其他腳本或Redis命令被執行。這種特性很好的解決了搶服務流程中并發帶來的問題。

REDIS+LUA搶購子流程：

此流程通過lua Script腳本實現，我們暫時命名為q.lua(主要功能限流和扣減促銷活動剩余數)。這樣把搶購流程與Script腳本結合，一次性提交給Redis減少網絡交互，使得性能大大提升。

q.lua偽代碼：

--[[ 
--!@brief 促銷Id下限流：可以防止某個促銷過熱導致服務不可以用 
--]] 
local function limited() 
    -- todo: 實現 
end 
--[[ 
--!@brief 限制邏輯(ip和pin)：比如有的促銷是限制ip,這里校驗ip是否存在,如果為限ip類型搶購活動,存在拋出異常告知ip已經存在不能搶購 
--]] 
local function check_ip_pin() 
    -- todo: 實現 
end 
--[[ 
--!@brief 記錄訂單號：主要目的實現搶方法冪等性,調用方網絡超時可以重復調用,存在訂單號直接返回搶購成功,不至于超賣 
--]] 
local function record_order_id() 
    -- todo: 實現 
end 
--[[ 
--!@brief 扣減剩余數 
--]] 
local function scalebuy() 
    -- 
    local lastNum = redis.call('HINCRBY',key,tag,-num); 
    -- 
end 
  
-- 調用順序不可調整 
-- 1 限流 
local status,msg = limited() 
if status == 0then 
    return msg 
end 
-- 2 校驗 
status,msg = check_ip_pin() 
if status == 0 then 
    return msg 
end 
-- 3 記錄訂單 
status,msg = record_order_id() 
if status == 0 then 
    return msg 
end 
-- 4 扣減剩余數 
status,msg = scalebuy() 
if status == 0 then 
    return msg 
end 
-- 5 返回成功標示 
return 1 

子流程具體如下：

1、解析請求參數，根據促銷Id按照Jedis中MurmurHash算法獲取分片，然后按照分片包裝Pipeline批量發送請求參數argList;

2、獲取系統初始化時SCRIPT LOAD加載q.lua返回的串shaValue;

3、執行EVALSHA，偽代碼如下：

// 其他操作 
Pipeline p; 
// 初始化p 
p.evalsha(shaValue,keyList, argList); 
// 其他操作 

4、處理返回結果，只要有一個分片失敗，本次搶購就失敗。

補充：詳細Script操作可以參考Jedis中 ScriptingCommandsTest。

JMQ發送子流程：

執行REDIS+LUA搶購子流程成功僅僅代表著操作redis成功，發送jmq(京東mq基礎服務)成功(后端異步將實時庫存更新到MySQL)才算一筆搶購成功，否則算搶購失敗。這么設計的原因主要是保證搶購redis和mysql記錄最終一致，發送失敗需要回滾REDIS+LUA搶購子流程(恢復Redis的庫存和搶購資格)。當然要考慮降級，jmq不可用時，直接切到jsf服務模擬jmq，也就是直接寫MySQL庫，前提是限流次數調小，否則數據庫有壓力過大的風險。這樣雖然用戶體驗下降了，但是服務依然可用。開關都在配置中心操作，一分鐘內生效。

資格回滾子流程：

發送JMQ失敗必須回滾，否則就出現了超賣現象，具體流程同REDIS+LUA搶購子流程類似，是它的逆向流程，只不過運行腳本不同罷了。

限流處理

方法級限流，限流閾值通過配置中心配置，一分鐘生效，偽代碼如下：

private static AtomicInteger atomic = new AtomicInteger(0); 
public void test() { 
    try { 
         // 限流 
        int limitNum = XXX.getLimitNum(); 
        int nowConcurrent = atomic.incrementAndGet(); 
        if(nowConcurrent > limitNum) { 
            // 異常處理 
        }   
        // 正常業務邏輯 
    } catch(Exception e) { 
        // 異常處理 
    } finally { 
        atomic.decrementAndGet(); 
    } 
} 

q.lua中促銷級別的限流，主要利用C_A_1中c的搶次數和閾值比對。比如促銷A，60秒內只能搶60000次，超過閾值60000該促銷就會搶購失敗。

到此搶購系統的核心邏輯就介紹完了，這里邊還有一些細節問題需要大家在設計時思考，如限購(如每個人限購2個)、真實庫存不足取消、用戶取消訂單歸還資格、Redis掛了恢復數據、停促銷(時間過期停、庫存不足停)等等。

作者：張子良，京東高級開發工程師，在京東負責搶購后端服務系統架構和開發工作。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

 

戳這里，看該作者更多好文