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

一、活動(dòng)背景

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

交互流程

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

二、大流量下的主要問(wèn)題

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

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

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

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

2. 高并發(fā)

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

3. 資金安全

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

三、設(shè)計(jì)方案

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

1. 延時(shí)放量

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

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

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

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

2. MQ 異步出款

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

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

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

2.1 定時(shí)任務(wù)

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

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

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

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

3.1 訂單冪等

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

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

3.2 對(duì)賬校驗(yàn)

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

準(zhǔn)實(shí)時(shí)對(duì)賬

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

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

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

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

2. 與財(cái)經(jīng)側(cè)準(zhǔn)實(shí)時(shí)對(duì)賬：

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

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

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

天級(jí)對(duì)賬

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

四、前期預(yù)案

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

1. 提前演練

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

2. 充分壓測(cè)

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

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

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

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

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

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

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

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

五、活動(dòng)總結(jié)

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

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