本文主要從服務(wù)端角度針對 2022 年春節(jié) Flower 活動中錢包提現(xiàn)模塊做一下總結(jié)與反思，希望可以對整個開發(fā)過程中使用的技術(shù)和遇到的問題進(jìn)行整理和沉淀，在后續(xù)類似的活動中可以產(chǎn)生一些幫助。

一、活動背景

與交互流程2022 年春節(jié)活動目標(biāo)是在抖音、火山、西瓜等八端啟動，希望抖音端能夠給多端進(jìn)行導(dǎo)流，實現(xiàn)“同一個字節(jié)，同一個春節(jié)”活動。對用戶來說，可以在任意一端參與春節(jié)活動并在錢包中看到集卡、紅包雨等玩法獲得的所有收入，最終可以在任一端提現(xiàn)春節(jié)收入至個人賬戶中，保證用戶在活動中的獎勵能夠落地，提升用戶春節(jié)活動參與度。

交互流程

用戶在進(jìn)入活動錢包頁后可查看參與活動獲得的獎勵收入，點擊【去提現(xiàn)】按鈕可以跳轉(zhuǎn)到提現(xiàn)頁面。在提現(xiàn)頁面用戶輸入提現(xiàn)的金額并選擇已綁定的到賬方式， 然后點擊【確認(rèn)提現(xiàn)】即可提現(xiàn)活動收入到自己選擇的個人賬戶中。

二、大流量下的主要問題

提現(xiàn)即用戶將自己通過參與集卡、紅包雨等活動玩法所活動的獎勵收入提取至用戶的銀行卡、支付寶或抖音零錢等個人賬戶中。由于春節(jié)活動存在集中開獎導(dǎo)致的高流量，活動發(fā)獎瓜分金額巨大等特點，在開發(fā)春節(jié)活動提現(xiàn)的過程中，有幾個方面需要重點考慮：

1. 入賬延遲與提現(xiàn)限制

除夕當(dāng)晚 19 點到 23 點每個整點開放紅包雨，19:30 春節(jié)活動集卡開獎與煙火大會啟動。此時面對上百萬 QPS 的用戶獎勵入賬，可能存在部分請求入賬存在延遲，導(dǎo)致用戶在提現(xiàn)的時候看到的金額與活動參與獲得獎勵金額不一致的情況。

此外今年春節(jié)活動提現(xiàn)增加了每筆訂單 1 元起提的門檻限制，在除夕晚上集卡開獎、紅包雨和煙火大會多個玩法的加持下，用戶很容易獲得 1 元以上的收入。但如果在獲得收入達(dá)到門檻后立即提現(xiàn)，可能會導(dǎo)致參加后續(xù)玩法獲得獎勵較少而無法提現(xiàn)的情況。

2. 高并發(fā)

集卡開獎與紅包雨后，提現(xiàn)入口打開時將面對幾十萬的請求流量，經(jīng)過用戶選擇到賬方式和輸入提現(xiàn)金額后也有數(shù)萬 QPS 的提現(xiàn)下單請求。錢包服務(wù)端收到請求后會操作扣除用戶的活動賬戶余額，接著調(diào)用財經(jīng)側(cè)(字節(jié)內(nèi)部的支付中臺)請求出款，財經(jīng)側(cè)維護(hù)與各支付機構(gòu)(支付寶、銀網(wǎng)聯(lián))的接入交互。但各支付機構(gòu)分配給各單位的出款請求流量有限額，字節(jié)這邊獲得的容量與提現(xiàn)出款相差了一個數(shù)量級。此時需要在保障用戶的提現(xiàn)體驗不受影響的同時，又能夠確保下游渠道側(cè)不會因流量較高導(dǎo)致可用性抖動。

3. 資金安全

提現(xiàn)是春節(jié)活動的最后一道流程，公司在用戶的春節(jié)活動收入賬戶進(jìn)行扣款并將資金通過預(yù)先設(shè)置的備付金賬戶轉(zhuǎn)入至端上綁定的個人賬戶中，從而使獲得的獎勵最終落地。如果用戶在端上的操作出現(xiàn)打款超額等情況，一旦出款成功則基本不會有追回的可能，因此，資金安全是提現(xiàn)業(yè)務(wù)開發(fā)過程中必須考慮并保證的部分，確保每筆出款有跡可循且符合提現(xiàn)規(guī)則。

三、設(shè)計方案

為解決上述問題，我們通過 RocketMQ 進(jìn)行異步出款來保證用戶體驗，同時 RocketMQ 的使用還可以對銀行卡等出款渠道進(jìn)行削峰來減少下游的過高流量。在資金安全方面，每筆訂單在進(jìn)行春節(jié)活動收入賬戶扣款和現(xiàn)金出款時做了冪等操作，并增加對賬任務(wù)對所有流水進(jìn)行對賬校驗。

1. 延時放量

除夕當(dāng)晚從 19:30 集卡活動開獎用戶進(jìn)入主會場即可看到集卡獎勵，同時煙火大會開啟參與活動即可獲得紅包獎勵，此外從 20:00 開始到 23:00 每個整點都會有紅包雨，用戶會不斷獲得春節(jié)活動獎勵并進(jìn)入錢包頁查看個人收入。

為保證用戶集卡開獎和紅包雨活動入賬順利，不會出現(xiàn)看到獎勵但錢包中無收入或收入不足導(dǎo)致提現(xiàn)錯誤的問題，我們在用戶進(jìn)入提現(xiàn)頁面的時候會根據(jù)端上請求參數(shù)中的紅包 token 列表進(jìn)行一次入賬請求，以確保用戶在確認(rèn)提現(xiàn)下單前賬戶中的金額如果沒有完成入賬的話可通過 token 列表進(jìn)行一次強制入賬，但為給用戶在提現(xiàn)頁面有較好體驗，此處的入賬為弱依賴請求。當(dāng)用戶確認(rèn)提現(xiàn)下單的時候，我們設(shè)置了強依賴性的強制入賬作為最終兜底方案，來使得最終提現(xiàn)扣款時獎勵金額已經(jīng)入賬成功并支持提現(xiàn)。

同時，為保證用戶可以在活動結(jié)束后提現(xiàn)參與獲得的所有獎勵，減少因提現(xiàn)門檻導(dǎo)致用戶參與后續(xù)玩法獲得獎勵較少而無法提現(xiàn)的情況，我們在春節(jié)活動中開啟了延時放量提現(xiàn)。從 19 點到凌晨 1 點之間關(guān)閉提現(xiàn)入口，用戶只能在主會場參與活動獲得獎勵，而無法進(jìn)入錢包頁面中進(jìn)行提現(xiàn)操作。當(dāng)用戶在活動錢包頁點擊【去提現(xiàn)】時，會彈窗提示用戶在 2 月 1 日 01:00 后可提現(xiàn)。此外，在彈窗中我們也加入了對用戶的綁卡營銷策略，引導(dǎo)用戶預(yù)先綁卡，提現(xiàn)快人一步。

隨著凌晨一點提現(xiàn)入口打開，可能會有大量用戶涌入提現(xiàn)頁面進(jìn)行提現(xiàn)。此時，為防止瞬間流量突增過高可能引發(fā)數(shù)據(jù)庫連接問題，我們通過在配置平臺上進(jìn)行配置，針對用戶 id 進(jìn)行取模后的結(jié)果進(jìn)行分批放開。在有限的情況下，確保用戶入賬無誤，請求不被限流是我們用戶體驗是否良好一個比較重要的評判因素。延遲到凌晨 1 點分批次放開提現(xiàn)有效降低了用戶提現(xiàn)的并發(fā)，保障了用戶提現(xiàn)體驗。

2. MQ 異步出款

在除夕當(dāng)天的晚上 19:00 到春節(jié)凌晨 01:00 時間段內(nèi)，春節(jié)活動錢包頁中會暫時關(guān)閉提現(xiàn)功能，進(jìn)行部分營銷導(dǎo)流。而隨著凌晨 01:00 提現(xiàn)開關(guān)打開，請求會蜂擁而至逐步上漲至數(shù)萬 QPS，但由于銀網(wǎng)聯(lián)的處理能力有限，導(dǎo)致銀行卡渠道出款最高可支持的 QPS 只有幾千。此時如果提現(xiàn)模塊不進(jìn)行限速下單的話，可能存在下游系統(tǒng)被壓垮引起雪崩的風(fēng)險，同時用戶會給感受到提現(xiàn)功能卡頓并頻繁失敗。

為解決該問題，我們引入了 RocketMQ 來進(jìn)行異步出款。當(dāng)用戶在錢包頁進(jìn)行提現(xiàn)操作時，服務(wù)端會在春節(jié)活動收入賬戶扣款完成后立即返回結(jié)果并跳轉(zhuǎn)至提現(xiàn)結(jié)果頁面展示當(dāng)前狀態(tài)，同時將當(dāng)前請求參數(shù)發(fā)送至 MQ 中進(jìn)行異步消費出款。這樣給用戶的感覺即賬戶余額已扣除，提現(xiàn)出款進(jìn)行中，稍后也可以通過賬單流水查詢提現(xiàn)結(jié)果。

將消息發(fā)送到 MQ 后，提現(xiàn)模塊利用 MQ 消費提現(xiàn)訂單的現(xiàn)金出款，通過下游消費者有限的消費能力進(jìn)行消息處理。同時增加自定義限流器對每個出款渠道進(jìn)行限流，利用 MQ 進(jìn)行流量削峰與限流出款兩種方式雙重保證了下游出款不會因流量過高而出現(xiàn)抖動。當(dāng)消費成功時則順利出款，當(dāng)消費失敗或被限流時則返回錯誤，MQ 會進(jìn)行消費重試。我們在這里設(shè)置 MQ 最大重試次數(shù)為 3 次，如果消息沒有超過最大重試次數(shù)，則被放入 retry 隊列;如果消息達(dá)到最大重試次數(shù)，則放入死信隊列不再處理。

2.1 定時任務(wù)

為防止提現(xiàn)訂單因 MQ 多次重試消費失敗或其他原因?qū)е聽顟B(tài)一只卡在某個中間狀態(tài)停止更新，我們額外設(shè)置了定時任務(wù)進(jìn)行補單操作推進(jìn)提現(xiàn)狀態(tài)。每小時固定從數(shù)據(jù)庫中撈取已被創(chuàng)建超過 4 個小時且當(dāng)前還處于未完成狀態(tài)的訂單，并根據(jù)其當(dāng)前狀態(tài)進(jìn)行推動：

• 待扣款的訂單，則說明用戶的賬戶收入還未進(jìn)行扣款，此時則直接將訂單狀態(tài)推進(jìn)為失敗狀態(tài);
• 待出款狀態(tài)的訂單，請求財經(jīng)接口進(jìn)行出款操作，推動狀態(tài)到出款中或出款完成;
• 出款中的訂單，查詢財經(jīng)出款訂單的狀態(tài)，如果財經(jīng)側(cè)已成功或失敗則將該狀態(tài)同步更新到提現(xiàn)訂單中，如果財經(jīng)側(cè)查單不到的話則調(diào)用財經(jīng)出款接口進(jìn)行重試;
• 對于從任一狀態(tài)流轉(zhuǎn)至失敗的訂單，我們會查詢賬戶的訂單流水，如果賬戶側(cè)存在余額扣減流水的話，則操作進(jìn)行余額退回，保證失敗的訂單不會扣減用戶的收入。

3. 提現(xiàn)資金安全

在提現(xiàn)的過程中，一旦技術(shù)方案設(shè)計有問題，容易存在資金安全問題：賬戶未扣款但現(xiàn)金已轉(zhuǎn)入用戶的個人賬戶，賬戶多次扣款或者現(xiàn)金多次出款等。因此，在春節(jié)活動中提現(xiàn)模塊的設(shè)計中，資金安全問題是重點考慮的部分。在提現(xiàn)請求發(fā)生時，服務(wù)端需要確保每筆訂單一定對應(yīng)一次賬戶余額扣減，一次現(xiàn)金出款。而提現(xiàn)完成后，需要有對賬任務(wù)與賬戶和財經(jīng)出款進(jìn)行對賬，分別對提現(xiàn)訂單的金額和狀態(tài)進(jìn)行校驗，保證事件中的驗證無誤。

3.1 訂單冪等

冪等，指任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。提現(xiàn)針對 orderID 做冪等性控制，在賬戶側(cè)每個 orderID 只有一筆扣款操作，從而保證用戶的活動賬戶余額不會被重復(fù)扣款;同時，在用戶當(dāng)前訂單提現(xiàn)失敗后進(jìn)行賬戶余額回滾操作時，首先查詢賬戶側(cè)是否存在扣款訂單，如果存在則進(jìn)行余額退回，退回時控制一筆扣款操作對應(yīng)一筆退回流水，防止出現(xiàn)多退的情況。

賬戶完成扣款之后，需要調(diào)用財經(jīng)的出款接口將資金從公司預(yù)先設(shè)置的備付金賬戶轉(zhuǎn)入至端上綁定的個人賬戶中，此時需要確保每筆提現(xiàn)請求只能有一次出款。在每次操作提現(xiàn)訂單進(jìn)行現(xiàn)金出款時，我們使用 redis 分布式鎖對 orderID 進(jìn)行加鎖操作，加鎖成功后判斷當(dāng)前訂單狀態(tài)，如果是待出款狀態(tài)則調(diào)用財經(jīng)接口進(jìn)行現(xiàn)金出款。在接口調(diào)用后立即更新訂單狀態(tài)為出款中，防止重復(fù)調(diào)用引發(fā)可能出現(xiàn)的重復(fù)出款操作。同時，財經(jīng)側(cè)也針對 orderID 做了冪等控制，確保每筆 orderID 都對應(yīng)一筆出款。

3.2 對賬校驗

涉及到資金流動，需要有對賬任務(wù)來保證上下游之間資金數(shù)據(jù)的一致性，能夠及時發(fā)現(xiàn)處理金額或狀態(tài)差異導(dǎo)致的資損問題。我們在對賬平臺分別增加了準(zhǔn)實時對賬和天級對賬來進(jìn)行資金的校驗。

準(zhǔn)實時對賬

在提現(xiàn)事件發(fā)生過程中，我們在對賬平臺中增加了與下游服務(wù)(賬戶、財經(jīng))提現(xiàn)數(shù)據(jù)的準(zhǔn)實時對賬，確保提現(xiàn)訂單每次狀態(tài)變化時都是準(zhǔn)確無誤的：

1. 與賬戶側(cè)準(zhǔn)實時對賬：

a. 在余額扣減成功后賬戶側(cè)會保存一筆提現(xiàn)扣款的數(shù)據(jù)流水，此時需要將扣減流水與提現(xiàn)訂單進(jìn)行金額和狀態(tài)校驗，確保扣款狀態(tài)和金額一致;

b. 在提現(xiàn)失敗的時候，如果此時賬戶側(cè)已經(jīng)扣款成功的話則需要將之前扣減的金額退回至用戶的活動賬戶中，此時需要在余額退回成功后進(jìn)行賬戶金額退回流水與提現(xiàn)訂單狀態(tài)、金額做校驗。

2. 與財經(jīng)側(cè)準(zhǔn)實時對賬：

a. 在提現(xiàn)訂單狀態(tài)更新為成功或失敗時，獲取財經(jīng)側(cè)的出款訂單數(shù)據(jù)與提現(xiàn)訂單數(shù)據(jù)進(jìn)行一致性校驗，判斷雙方數(shù)據(jù)的狀態(tài)、金額是否一致。

對賬平臺中的數(shù)據(jù)校驗，是基于數(shù)據(jù)雙方的 binlog 消費進(jìn)行的準(zhǔn)實時對賬，在對賬雙方任一方缺失數(shù)據(jù)或雙方對賬狀態(tài)金額出現(xiàn)不一致的情況下便會發(fā)送飛書報警通知。

此外，我們還在線上服務(wù)中增加了自主對賬任務(wù)，通過消費提現(xiàn)數(shù)據(jù)庫的 binlog 消息。針對其中到達(dá)終態(tài)的訂單，我們會根據(jù)訂單狀態(tài)分別通過接口調(diào)用的方式對賬戶、財經(jīng)側(cè)進(jìn)行查單檢查。成功的提現(xiàn)訂單在賬戶的查單接口中可以查到一筆扣款流水，在財經(jīng)的查單接口中也會有一筆出款成功的訂單。而失敗的提現(xiàn)訂單在賬戶的查單接口中可以查到一筆扣款和一筆退回余額的流水，在財經(jīng)的查單接口中如果可以查到訂單的話則只有失敗訂單，如果沒有訂單的話說明提現(xiàn)流程還沒有走到出款便失敗了，此時可忽略缺失的差異。

天級對賬

另外，我們也增加了與下游服務(wù)(賬戶、財經(jīng))的天級對賬，作為準(zhǔn)實時對賬之外的一種兜底對賬。因為上下游之間可能因調(diào)用失敗或者回調(diào)失敗導(dǎo)致狀態(tài)同步不及時，我們增加了定時任務(wù)進(jìn)行訂單狀態(tài)推進(jìn)，保證每筆提現(xiàn)訂單最終都可以達(dá)到終態(tài)。天級對賬即為了解決狀態(tài)同步不及時可能引發(fā)的準(zhǔn)實時對賬差異，通過每天生成的 hive 數(shù)據(jù)進(jìn)行狀態(tài)和金額校驗，減少時間差產(chǎn)生的誤報。

四、前期預(yù)案

為保證活動上線后用戶能夠在錢包頁中進(jìn)行正常提現(xiàn)，我們在活動開始前增加了準(zhǔn)備預(yù)案。

1. 提前演練

在活動正式開始前，我們組織了內(nèi)部圈定人群、內(nèi)部所有人、外部圈定城市等三次預(yù)演，針對春節(jié)活動紅包雨和現(xiàn)金提現(xiàn)進(jìn)行了提前演練，模擬春節(jié)活動的正常流程與突發(fā)情況的處理。通過演練，我們可以提前發(fā)現(xiàn)整個活動流程是否順利，并將可能存在的問題提前暴露解決。

2. 充分壓測

為支持春節(jié)活動過程中產(chǎn)生的大流量請求，保證給用戶提供良好的活動體驗，我們將春節(jié)活動現(xiàn)金提現(xiàn)與錢包日常收入提現(xiàn)的功能進(jìn)行了集群隔離。在代碼開發(fā)上線后，申請壓測資源對各業(yè)務(wù)流程進(jìn)行了預(yù)估流量壓測，集群隔離也使得壓測操作不會對線上正常業(yè)務(wù)有任何影響。

在提現(xiàn)業(yè)務(wù)壓測的過程中，有兩個方面需要做一些數(shù)據(jù)準(zhǔn)備：

• 查詢到賬方式接口需要對壓測的 uid 構(gòu)造已綁定的到賬方式結(jié)果返回;
• 確認(rèn)提現(xiàn)下單接口需要對壓測的 uid 有綁定到賬方式的同時，還需要 uid 對應(yīng)的活動賬戶中有足夠的金額支持余額扣減。為解決此問題，財經(jīng)的同學(xué)在壓測之前提供了一批已綁定到賬方式的測試 uid 生成的文件， 方便我們在進(jìn)行到賬方式查詢接口壓測的時候能夠從文件中指定 uid 參數(shù)。

另外，在賬戶同學(xué)壓測入賬接口的時候，我們提供了該文件讓其幫助對這批 uid 進(jìn)行入賬。如此在壓測提現(xiàn)下單的時候，我們使用已經(jīng)綁定到賬方式的測試 uid 數(shù)據(jù)，其活動賬戶中已經(jīng)存在余額可支持提現(xiàn)余額扣減。

最終，通過對到賬方式查詢、確認(rèn)提現(xiàn)下單等接口進(jìn)行全鏈路壓測后，我們能夠準(zhǔn)確評估了為支持春節(jié)活動最高 QPS 所需的各項資源容量，使春節(jié)活動可按照預(yù)先計算的流量支持用戶操作提現(xiàn)。

3. 除夕當(dāng)日執(zhí)行劇本

除夕是我們春節(jié)活動啟動后的重要時間點，當(dāng)天有多場紅包雨，同時還有煙火大會和集卡開獎等玩法出現(xiàn)，整個活動會在春節(jié)聯(lián)歡晚會開始的時候達(dá)到高潮。在這種大型活動參與過程中，每個人或多或少都會有一些壓力在身上?？v使代碼經(jīng)過驗證，前期進(jìn)行過多次演練均無問題，但還是需要抱有謹(jǐn)慎的態(tài)度來應(yīng)對重要活動的開始。在大腦記憶力有限的情況下，為防止出現(xiàn)遺漏，我們針對除夕當(dāng)天寫了執(zhí)行劇本：

• 執(zhí)行細(xì)節(jié)。從除夕上午十點開始到初一凌晨兩點，每場紅包雨前需要做什么準(zhǔn)備，紅包雨發(fā)生時需要查看哪些監(jiān)控指標(biāo)，紅包雨后是否需要記錄數(shù)據(jù)等，執(zhí)行劇本需要詳細(xì)記錄每個時間點需要做的事情。
• 配置校驗。提現(xiàn)業(yè)務(wù)在春節(jié)活動上有活動配置與限流等。在活動開始前需要再次做一遍檢查，確保各項配置和限流均正確無誤。
• 容災(zāi)方案。除執(zhí)行細(xì)節(jié)和配置校驗外，我們還在劇本中加入了容災(zāi)預(yù)案，方便在某項流程出現(xiàn)問題的時候能夠及時根據(jù)預(yù)案進(jìn)行處理。
• 交叉檢查。劇本中的各項操作細(xì)節(jié)和配置檢查均為兩個人分工進(jìn)行，通過交叉檢查的方式防止出現(xiàn)一人疏忽大意而錯誤改動的情況。

五、活動總結(jié)

春節(jié)活動上線后，用戶積極參與各種玩法并在其活動錢包中進(jìn)行現(xiàn)金提現(xiàn)。在除夕當(dāng)晚，延時放量雖然使用戶在獲得收入的第一時間不能進(jìn)行提現(xiàn)，但用戶獎勵入賬正常，延時放開后提現(xiàn)請求沒有被出款渠道限流，有效地保障了用戶提現(xiàn)體驗。同時，在渠道側(cè)出款能力有限的情況下，通過使用 MQ 進(jìn)行異步出款有效地限制了對下游服務(wù)的請求流量，使其沒有因流量過高而導(dǎo)致出款異常。

此外，在春節(jié)活動的整個時間段內(nèi)，通過對提現(xiàn)流程進(jìn)行風(fēng)險梳理，增加對賬平臺準(zhǔn)實時與小時級對賬支持和線上服務(wù)對賬支持，雙重保障了春節(jié)活動現(xiàn)金提現(xiàn)模塊對賬任務(wù)的全覆蓋，使用戶在參與活動并收獲獎勵進(jìn)行提現(xiàn)的過程中未對其造成資金損失，確保了用戶的參與度。