摘要：活動規(guī)模既然公司對自如客這么闊，那對我們員工也得夠意思，所以年底我們共準(zhǔn)備了個(gè)活動。拆分后，紅包占有只需操作，響應(yīng)性能已不是問題。

首發(fā)于 樊浩柏科學(xué)院

2017 年是自如快速增長的一年，自如客突破 100 萬，管理資產(chǎn)達(dá)到 50 萬間，在年底成功獲得了 40 億 A 輪融資，而這些都要感謝廣大的自如客，公司為了回饋?zhàn)匀缈?，在六周年活動時(shí)就發(fā)放了 6000 萬租住基金，當(dāng)然年底散幣活動也夠瘋狂。

既然公司對自如客這么闊，那對我們員工也得夠意思，所以年底我們共準(zhǔn)備了 3 個(gè)活動。

1、針對 自如客 的服務(wù)費(fèi)減免活動；
2、針對 自如客 的 1000 萬現(xiàn)金禮包；
3、25 萬的 員工 紅包活動；

散幣活動 2 和 3 是通過微信紅包形式進(jìn)行，想散幣就散吧，可微信告訴我們，想散幣還得交稅（>﹏<）。員工紅包來說，25 萬要交掉 10 多萬稅，此時(shí)心疼我的錢。好了，下面開始說點(diǎn)正事。

說到紅包，我們肯定會想到紅包拆分和搶紅包兩個(gè)場景。紅包拆分是指將指定金額拆分為指定數(shù)目紅包的過程，即是用來確定每個(gè)紅包的金額數(shù)；而搶紅包就是典型的高并發(fā)場景，需要避免紅包超發(fā)的情況。

拆分方式

1、實(shí)時(shí)拆分
實(shí)時(shí)拆分，指的是在搶紅包時(shí)實(shí)時(shí)計(jì)算每個(gè)紅包的金額，以實(shí)現(xiàn)紅包的拆分過程，對系統(tǒng)性能和拆分算法要求較高，例如拆分過程要一直保證后續(xù)待拆分紅包的金額不能為空，不容易做到拆分紅包的金額服從正態(tài)分布規(guī)律。

2、預(yù)先生成
預(yù)先生成，指的是在紅包開搶之前已經(jīng)完成了紅包的拆分，搶紅包時(shí)只是依次取出拆分好的紅包金額，對拆分算法要求較低，可以拆分出隨機(jī)性很好的紅包金額，通常需要結(jié)合隊(duì)列使用。

拆分算法

我并沒有找到業(yè)界的通用算法，但紅包拆分算法應(yīng)該是拆分金額要看起來隨機(jī)，最好能夠服從正態(tài)分布，可以參考 微信 和 @lcode 提供的紅包拆分算法。

微信拆分算法的優(yōu)點(diǎn)是算法較簡單，拆分效率高，同時(shí)，由于該算法天然的特性，可以保證后續(xù)紅包金額一定不為空，特別適合實(shí)時(shí)拆分場景，但缺點(diǎn)是會導(dǎo)致大額紅包較大概率地在拆分的最后出現(xiàn)。 @lcode 拆分算法的優(yōu)點(diǎn)是拆分金額基本符合正態(tài)分布，適合隨機(jī)性要求較高的拆分場景。

我們這次的業(yè)務(wù)對紅包金額的隨機(jī)性要求不高，但是對系統(tǒng)可靠性要求較高，所以我們選用了預(yù)算生成方式，使用 二倍均值法 的紅包拆分算法，作為我們的紅包拆分方案。

采用預(yù)算生成方式，我們預(yù)先生成紅包并放入 Redis 的 List 中，當(dāng)搶紅包時(shí)只是 Pop List 即可，具體實(shí)現(xiàn)將在 搶紅包 部分介紹。

拆分算法可以描述為：假設(shè)剩余拆分金額為 M，剩余待拆分紅包個(gè)數(shù)為 N，紅包最小金額為 1 元，紅包最小單位為元，那么定義當(dāng)前紅包的金額為：

$$m = rand(1, floor(M/N*2))$$

其中，floor 表示向下取整，rand(min, max) 表示從 [min, max] 區(qū)間隨機(jī)一個(gè)值。$M/N ast 2$ 表示剩余待拆分金額平均金額的 2 倍，因?yàn)?N >= 2，所以 $M/N ast 2 <= M$，表示一定能保證后續(xù)紅包能拆分到金額。

代碼實(shí)現(xiàn)為：

for ($i = 0; $i < $N - 1; $i++) {
    $max = (int)floor($M / ($N - $i)) * 2;
    $m[$i] = $max ? mt_rand(1, $max) : 0;
    $M -= $m[$i];
}

$m[] = $M;

值得一提的是，我們?yōu)榱吮ＷC紅包金額差異盡量小，先將總金額平均拆分成 N+1 份，將第 N+1 份紅包按照上述的紅包拆分算法拆分成 N 份，這 N 份紅包加上之前的平均金額才作為最終的紅包金額。

限流

1、前端限流
前端限制用戶在 n 秒之內(nèi)只能提交一次請求，雖然這種方式只能擋住小白，不過這是 99% 的用戶喲，所以也必須得做。

2、后端限流
常用的后端限流方法有 漏桶算法 和 令牌桶算法。漏桶算法 主要目的是控制請求數(shù)據(jù)注入的速率，如果此時(shí)漏桶溢出，后續(xù)的請求數(shù)據(jù)會被丟棄。而 令牌桶算法 是以一個(gè)恒定的速度往桶里放入令牌，而如果請求數(shù)據(jù)需要被處理，則需要先從桶里獲取一個(gè)令牌，當(dāng)桶里沒有令牌時(shí)，這些請求才被丟棄，令牌桶算法的一個(gè)好處是可以方便地改變應(yīng)用接受請求的速率。

防超發(fā)

1、庫存加鎖
可以通過加鎖的方式解決資源搶占問題，但是加鎖會增加系統(tǒng)開銷，大流量下更容易拖垮系統(tǒng)，不過可以嘗試一下基于版本號的樂觀鎖。

2、通過高速隊(duì)列串行化請求
之所會出現(xiàn)超發(fā)問題，是因?yàn)椴l(fā)時(shí)會出現(xiàn)多個(gè)進(jìn)程同時(shí)獲取同一資源的現(xiàn)象，如果使用高速隊(duì)列將并行請求串行化，那么問題就不存在了。高速隊(duì)列可以使用 Redis 緩存服務(wù)器來實(shí)現(xiàn)，當(dāng)然光使用隊(duì)列還不夠，必要保證整個(gè)流程調(diào)用鏈要短、要快，否則隊(duì)列會積壓嚴(yán)重，甚至?xí)峡逭麄€(gè)服務(wù)。

在限流方面，由于我們預(yù)估的請求量還在系統(tǒng)承受范圍，所以沒有考慮引入后端限流方案。我們的搶紅包系統(tǒng)流程圖如下：

我們將搶紅包拆分為 紅包占有（流程①，同步） 和 紅包發(fā)放 （流程②，異步）這兩個(gè)過程，首先采用高速隊(duì)列串行化請求，紅包發(fā)放邏輯由一組 Worker 異步去完成。高速隊(duì)列只是完成紅包占有的過程，實(shí)現(xiàn)庫存的控制，Worker 則處理耗時(shí)較長的紅包發(fā)放過程。

當(dāng)然，在實(shí)際應(yīng)用中，紅包占用過程還需要加上一些前置規(guī)則校驗(yàn)，比如用戶是否已經(jīng)領(lǐng)取過，領(lǐng)取次數(shù)是否已經(jīng)達(dá)到上限等？紅包占有流程圖如下：

其中，red::list為 List 結(jié)構(gòu)，存放預(yù)先生成的紅包金額（流程①中的紅包隊(duì)列）；red::task 也為 List 結(jié)構(gòu)，紅包異步發(fā)放隊(duì)列（流程②中的任務(wù)隊(duì)列）；red::draw為 Hash 結(jié)構(gòu)，存放紅包領(lǐng)取記錄，field為用戶的 openid，value為序列化的紅包信息；red::draw_count:u:openid為 k-v 結(jié)構(gòu)，用戶領(lǐng)取紅包計(jì)數(shù)器。

下面，我將以以下 3 個(gè)問題為中心，來說說我們設(shè)計(jì)出的搶紅包系統(tǒng)。

1、怎么保證不超發(fā)
我們需要關(guān)注的是紅包占有過程，從紅包占有流程圖可看出，這個(gè)過程是很多 Key 操作的組合，那怎么保證原子性？可以使用 Redis 事務(wù)，但我們選用了 Lua 方案，一方面是因?yàn)槭紫纫ＷC性能，而 Lua 腳本嵌入 Redis 執(zhí)行不存在性能瓶頸，另一方面 Lua 腳本執(zhí)行時(shí)本身就是原子性的，滿足需求。

紅包占有的 Lua 腳本實(shí)現(xiàn)如下：

-- 領(lǐng)取人的openid為xxxxxxxxxxx
local openid = "xxxxxxxxxxx"
local isDraw = redis.call("HEXISTS", "red::draw", openid)
-- 已經(jīng)領(lǐng)取
if isDraw ~= 0 then
    return true
end
-- 領(lǐng)取太多次了
local times = redis.call("INCR", "red::draw_count:u:"..openid)
if times and tonumber(times) > 9 then
    return 0
end

local number = redis.call("RPOP", "red::list")
-- 沒有紅包
if not number then
    return {}
end
-- 領(lǐng)取人昵稱為Fhb,頭像為https://xxxxxxx
local red = {money=number,name="Fhb",pic="https://xxxxxxx"}
-- 領(lǐng)取記錄
redis.call("HSET", "red::draw", openid, cjson.encode(red))
-- 處理隊(duì)列
red["openid"] = openid
redis.call("RPUSH", "red::task", cjson.encode(red))

return true

需要注意 Lua 腳本執(zhí)行過程并不是事務(wù)的，腳本中的操作命令在執(zhí)行時(shí)是有先后順序的，當(dāng)某個(gè)操作執(zhí)行失敗時(shí)不會回滾已經(jīng)執(zhí)行成功的操作，它的原子性是通過單線程模型實(shí)現(xiàn)。

2、怎么提高系統(tǒng)響應(yīng)速度
如紅包占有流程圖所示，當(dāng)用戶發(fā)起搶紅包請求時(shí)，若有紅包則直接完成紅包占有操作，同步告知用戶是否搶到紅包，這個(gè)過程要求快速響應(yīng)。

但由于微信紅包支付屬于第三方調(diào)用，若搶到紅包后同步調(diào)用紅包支付，系統(tǒng)調(diào)用鏈又長又慢，所以紅包占有和紅包發(fā)放異步拆分是必然。拆分后，紅包占有只需操作 Redis，響應(yīng)性能已不是問題。

3、怎么提高系統(tǒng)處理能力
從上述分析可知，目前系統(tǒng)的壓力都會集中在紅包發(fā)放這個(gè)環(huán)節(jié)，因?yàn)橛脩魮尩郊t包時(shí)，我們只是同步告知用戶已搶到紅包，然后異步去發(fā)放紅包，因此用戶并不會立即收到紅包（受紅包發(fā)放 Worker 處理能力和微信服務(wù)壓力制約）。若紅包發(fā)放的 Worker 處理能力較弱，那么紅包發(fā)放的延遲就會很高，體驗(yàn)較差。

如搶紅包流程圖中所示，我們采用一組 Worker 去消費(fèi)任務(wù)隊(duì)列，并調(diào)用紅包支付 API，以及數(shù)據(jù)持久化操作（后續(xù)對賬）。盡管紅包發(fā)放調(diào)用鏈又長又慢，但是注意到這些 Worker 是 無狀態(tài) 的，所以可以通過增加 Worker 數(shù)量，以橫向擴(kuò)展提高系統(tǒng)的處理能力。

4、怎么保證數(shù)據(jù)一致性
其實(shí)，紅包發(fā)放延時(shí)我們可以做到用戶無感知，但是若紅包發(fā)放（流程②）失敗了，已經(jīng)告知用戶搶到紅包，但是卻木有發(fā)，估計(jì)他殺人的心都有了。根據(jù) CAP 原理，我們無法同時(shí)滿足數(shù)據(jù)一致性、數(shù)據(jù)可用性、分區(qū)耐受性，通常只需做到數(shù)據(jù)最終一致性。

為了達(dá)到數(shù)據(jù)最終一致性，我們就引入了重試機(jī)制，生成一個(gè)全局唯一的外部訂單號，當(dāng)某單紅包發(fā)放失敗，就會放回任務(wù)隊(duì)列，使得有機(jī)會進(jìn)行發(fā)放重試，當(dāng)然這一切都需要 API 做冪等處理。

這里必須將 Worker 可靠性多帶帶說，因?yàn)樗鼘?shí)在太重要了。Worker 的實(shí)現(xiàn)如下：

$maxTask = 1000;
$sleepTime = 1000;

while (true) {
    while ($red = RedLogic::getTask()) {
        RedLogic::doTask($red);
        //處理多少個(gè)任務(wù)主動退出
        $maxTask--;
        if ($maxTask < 0) {
            return EXIT_CODE_NORMAL;
        }
    }
    //等待任務(wù)
    usleep($sleepTime);
}

這里使用 LPOP 命令獲取任務(wù)，所以使用了 while 結(jié)構(gòu)，并且無任務(wù)時(shí)需要等待，可以用阻塞命令 BLPOP 來改進(jìn)。

由于 Worker 需要常駐內(nèi)存運(yùn)行，難免會出現(xiàn)異常退出的情況（也有主動退出）， 所以需要保持 Worker 一直處于運(yùn)行狀態(tài)。我們使用進(jìn)程管理工具 Supervisor 來監(jiān)控 Worker 的運(yùn)行狀態(tài)，同時(shí)管理 Worker 的數(shù)量，當(dāng)任務(wù)隊(duì)列出現(xiàn)堆積時(shí)，增加 Worker 數(shù)量即可。Supervisor 的監(jiān)控后臺如下：

公司員工都用唯一一個(gè)系統(tǒng)號 emp_code（自增字段）標(biāo)識，登錄成功后返回 emp_code，系統(tǒng)后續(xù)所有交互流程都基于 emp_code，分享出去的紅包也會攜帶 emp_code，為了保護(hù)員工敏感信息和防止惡意碰撞攻擊，我們不能直接將 emp_code 暴露給前端，需要借助一個(gè) token（無規(guī)律）的中間者來完成交互。

1、儲存映射關(guān)系，時(shí)時(shí)查詢
預(yù)先生成一個(gè)隨機(jī)串 token，然后跟 emp_code 綁定，每次請求都根據(jù) token 時(shí)時(shí)查詢 emp_code。優(yōu)點(diǎn)是可以定期更新，相對安全，缺點(diǎn)是性能不高。

2、建立映射關(guān)系函數(shù)，實(shí)時(shí)計(jì)算
建立一個(gè)映射關(guān)系函數(shù)，如 hash 散列或者加密解密算法，能夠根據(jù) emp_code 生成一個(gè)無規(guī)律的字符串 token，并且要能夠根據(jù) token 反映射出 emp_code。優(yōu)點(diǎn)是需要存儲介質(zhì)存儲關(guān)系，性能較高，缺點(diǎn)是很難做到定期失效并更新。

由于我們的紅包活動只進(jìn)行幾天，所以我們選用了方案 2。對 emp_code 做了 hashids 散列算法，暴露的只是一串無規(guī)律的散列字符串。

hashids 是一個(gè)開源且輕量的唯一 id 生成器，支持 Java、PHP、C/C++、Python 等主流語言，PHP 想使用 hashids，只需composer require hashids/hashids命令安裝即可。

然后，如下方式使用：

use HashidsHashids;

$hashids = new Hashids("salt", 6, "abcdefghijk1234567890");

$hashids->encode(11002);    //994k2kk
$hashids->decode("994k2kk");  //[11002]

需要說明的是，其中salt是非常重要的散列加密鹽串，6表示散列值最小長度，abcde...7890為散列字典，太長影響效率，太短不安全。由于默認(rèn)的散列字典比較長，decode 效率并不高，所以這里移除了大寫字母部分。

語音點(diǎn)贊就是用戶以語音的形式助力好友，核心技術(shù)其實(shí)是語音識別，而我們一般都會使用第三方語音識別服務(wù)。

1、客戶端調(diào)用第三方服務(wù)識別
客戶端直接調(diào)用第三方語音識別服務(wù)，如微信提供了 JS-SDK 的語音識別 API ，返回識別的語音文本的信息，并且已經(jīng)經(jīng)過語義化。優(yōu)點(diǎn)是識別較快，且不許關(guān)注語音存儲問題，缺點(diǎn)是不安全，識別結(jié)果提交到服務(wù)端之前可能被惡意篡改。

2、服務(wù)端調(diào)用第三方服務(wù)識別
先將錄制的語音上傳至存儲平臺，然后服務(wù)端調(diào)用第三方語音識別服務(wù)，第三方語音識別服務(wù)去獲取語音信息并識別，返回識別的語音文本的信息。優(yōu)點(diǎn)是識別結(jié)果較安全，缺點(diǎn)是系統(tǒng)交互較多，識別效率不高。

我們業(yè)務(wù)場景的特殊性，存在用戶可助力次數(shù)的限制，所以無需擔(dān)心惡意刷贊的情況，因此可以選用方案 1，語音識別的交互流程如下：

此時(shí)，整個(gè)語音識別流程如下：

當(dāng)然中國文字博大精深，語音識別的文本在匹配時(shí)，需要考慮容錯(cuò)處理，可以將文本轉(zhuǎn)化為拼音，然后匹配拼音，或者設(shè)置一個(gè)匹配百分比，達(dá)到匹配值則認(rèn)為語音口令正確。

需要注意的是，微信只提供 3 天的語音存儲服務(wù)，若語音播放周期較長，則要考慮實(shí)現(xiàn)語音的存儲。

我們使用了線上公賬號進(jìn)行紅包發(fā)放測試，為了讓線上公眾號能夠授權(quán)到測試環(huán)境，在線上的微信授權(quán)回調(diào)地址新增一個(gè)參數(shù)，將帶有to=feature參數(shù)的請求引流到測試環(huán)境，其他線上流量還是保持不變，匹配規(guī)則如下：

# Nginx不支持if嵌套，所以就這樣變通實(shí)現(xiàn)
set $auth_redirect "";
if ($args ~* "r=auth/redirect") {
    set $auth_redirect "prod";
}
if ($args ~* "to=feature") {
    set $auth_redirect "feature";
}
if ($auth_redirect ~ "feature") {
    rewrite ^(.*)$ http://wx.t.ziroom.com/index.php last;
}
if ($auth_redirect ~ "prod") {
    rewrite ^(.*)$ http://wx.ziroom.com/index.php last;
}

由于本次活動力度較大，預(yù)估流量會比以往增加不少（不能再出現(xiàn)機(jī)房帶寬打滿的情況了，不然 >﹏<），靜態(tài)頁面占流量的很大一部分，所以靜態(tài)頁面在發(fā)布時(shí)都會放置一份在 CDN 上，這樣回源的流量就很小了。

盡管做了很多準(zhǔn)備，還是無法確保萬無一失，我們在每個(gè)關(guān)鍵節(jié)點(diǎn)都增加了開關(guān)，一點(diǎn)出現(xiàn)異常，通過配置中心可以人工介入做降級處理。