我們做了什么

業(yè)務(wù)背景

在春節(jié)活動期間，抖音將視頻和春節(jié)紅包相結(jié)合，用戶可以通過拍視頻發(fā)紅包的方式來給粉絲和好友送祝福。

業(yè)務(wù)玩法

整個活動玩法分為 B2C 和 C2C 兩種玩法，下面對這兩個玩法的流程簡單介紹下

b2c 紅包

在 B2C 紅包玩法中，用戶需要先來抖音或者抖 Lite 參加春節(jié)紅包雨活動，有一定概率在春節(jié)紅包雨活動中獲得紅包補貼。用戶可以在獲得補貼后直接跳轉(zhuǎn)到相機頁面，或者在之后拍攝視頻跳轉(zhuǎn)到相機頁面，在相機頁面用戶拍攝完視頻后會看到一個紅包掛件，在掛件中可以看到已發(fā)放補貼。用戶選擇補貼后點擊下一步完成投稿后即可完成視頻紅包的發(fā)放。

C2C 紅包

在 C2C 紅包玩法中，用戶拍攝視頻點擊掛件，填寫紅包的金額和個數(shù)信息，選擇紅包的領(lǐng)取范圍后，點擊發(fā)送紅包會拉起收銀臺，用戶支付完成后點擊下一步發(fā)布視頻，即可完成 C2C 紅包的發(fā)放。

紅包領(lǐng)取

B2C 和 C2C 紅包的領(lǐng)取流程都是一樣的。用戶在抖音刷視頻遇到有視頻紅包的視頻時，視頻下方有個領(lǐng)取紅包按鈕，用戶點擊紅包領(lǐng)取，會彈出到紅包封面，用戶點擊紅包封面的開紅包后即可領(lǐng)取紅包，領(lǐng)取成功后會顯示領(lǐng)取結(jié)果彈窗，在領(lǐng)取結(jié)果中用戶可以看領(lǐng)取金額，以及跳轉(zhuǎn)到領(lǐng)取詳情頁，在領(lǐng)取詳情頁中可以看到這個紅包其他用戶的領(lǐng)取手氣。

衛(wèi)視春晚演示視頻

C2C 視頻紅包在衛(wèi)視春晚上也有推廣，這里貼一個衛(wèi)視春晚的推廣視頻，方便大家了解下整體流程。

我們碰到的一些問題

通用紅包系統(tǒng)的設(shè)計

在上文中有提到，本次春節(jié)活動需要同時支持 B2C 和 C2C 兩種類型的紅包，這兩個類型的紅包既有一些相似的業(yè)務(wù)，也有很多不同的業(yè)務(wù)。在相同點上他們都包括紅包的發(fā)放和領(lǐng)取這兩個操作。在不同點上，比如 B2C 的紅包發(fā)放需要通過使用補貼來發(fā)送，而 C2C 的紅包發(fā)放需要用戶去完成支付。B2C 的紅包用戶領(lǐng)取后需要去提現(xiàn)，而 C2C 的紅包用戶領(lǐng)取后直接到零錢。因此需要設(shè)計一個通用的紅包系統(tǒng)來支持多種紅包類型。

另外對于紅包系統(tǒng)本身而言，除了發(fā)領(lǐng)紅包外，還涉及到一些紅包信息的查詢，以及各種狀態(tài)機的推進，這些功能模塊之間如何劃分也是需要考慮的一個點。

大流量補貼的發(fā)放處理

前面提到過，B2C 紅包玩法會先進行補貼的發(fā)放。在春節(jié)活動期間，每場紅包雨都會有大量的用戶進入?yún)⑴c，如果將這些流量直接打到數(shù)據(jù)庫，將需要大量的數(shù)據(jù)庫資源，而春節(jié)期間數(shù)據(jù)庫的資源是非常稀缺的，如何減少這部分的資源消耗也是一個需要考慮的問題。

紅包領(lǐng)取方案的選型

在紅包業(yè)務(wù)中，領(lǐng)取是一個高頻的操作，在領(lǐng)取方式的設(shè)計中，需要業(yè)務(wù)場景考慮一個紅包是否會被多個用戶同時領(lǐng)取。多個用戶同時去領(lǐng)取同一個紅包可能會導(dǎo)致熱點賬戶問題，成為系統(tǒng)性能的瓶頸。解決熱點賬戶問題也有多個方案，我們需要結(jié)合視頻紅包的業(yè)務(wù)場景特點來選取合適的方案。

穩(wěn)定性容災(zāi)

在本次春節(jié)活動中，包括 B2C 和 C2C 兩種業(yè)務(wù)流程，其中每個業(yè)務(wù)流量鏈路都依賴很多的下游服務(wù)和基礎(chǔ)服務(wù)。在這種大型活動中，如果出現(xiàn)黑天鵝事件時，如何快速止損，減少對系統(tǒng)的整體影響，是一個必須要考慮的問題。

資金安全保證

在春節(jié)活動期間，B2C 會發(fā)放大量的紅包補貼，如果補貼發(fā)生超發(fā)，或者補貼的核銷出現(xiàn)問題，一個補貼被多次核銷，將會造成大量的資損。另外 C2C 也涉及到用戶的資金流入流出，如果用戶領(lǐng)取紅包后如果發(fā)現(xiàn)錢變少了，也可能會造成大量的客訴和資損。因此資金安全這塊需要做好充足的準(zhǔn)備。

紅包系統(tǒng)的壓測

在傳統(tǒng)的壓測方式中，我們一般會對某個大流量接口進行壓測從而得到系統(tǒng)的瓶頸。然而在紅包系統(tǒng)中，用戶的發(fā)領(lǐng)和查都是同時進行的，并且這幾個接口之間也是相互依賴的，比如需要先發(fā)紅包，有了紅包后才能觸發(fā)多個人的領(lǐng)取，領(lǐng)取完成后才可以查看領(lǐng)取詳情。如果使用傳統(tǒng)的單接口的壓測方式，首先 mock 數(shù)據(jù)會非常困難，和支付相應(yīng)的壓測數(shù)據(jù)因為涉及實名還需要特殊生成，而且單個接口單個接口的壓測很難得到系統(tǒng)的真實瓶頸，因此如何對系統(tǒng)進行全鏈路的壓測從而得到系統(tǒng)準(zhǔn)確的瓶頸也是我們需要解決的一個問題。

我們怎么做的

通用紅包系統(tǒng)的設(shè)計

對于紅包系統(tǒng)，核心操作包括紅包發(fā)送，領(lǐng)取，以及未領(lǐng)取的退款這三個操作。另外我們還會需要去查一些紅包的信息和領(lǐng)取的信息等。同時對于發(fā)送，領(lǐng)取和退款這三個核心操作，我們需要對它們的狀態(tài)進行一個維護。同時在我們的業(yè)務(wù)場景中，還存在 B2C 特有的補貼的發(fā)放，我們也需要維護補貼的狀態(tài)。

在上面初步介紹紅包系統(tǒng)后，可以看到紅包的幾個功能模塊，有發(fā)放，領(lǐng)取，退款，補貼發(fā)放以及各種信息查詢，另外還有狀態(tài)機的維護等，對紅包的功能進行梳理后，我們開始對紅包的模塊進行劃分。

劃分原則

• 功能內(nèi)聚，每個系統(tǒng)只處理一個任務(wù)，方便之后系統(tǒng)的開發(fā)和迭代，以及問題的排查
• API 網(wǎng)關(guān)層只進行簡單的 proxy 處理
• 異步任務(wù)拆解
• 讀寫分離，將紅包的核心操作和紅包的查詢分成兩個服務(wù)

劃分模塊

• 紅包網(wǎng)關(guān)服務(wù)
• HTTP API 網(wǎng)關(guān)，對外對接客戶端和 h5，對內(nèi)封裝各個系統(tǒng) rpc 接口，限流，權(quán)限控制、降級等功能
• 紅包核心服務(wù)
• 主要承載紅包核心功能，包括紅包的發(fā)放、領(lǐng)取、退款，以及紅包補貼的發(fā)放，維護紅包狀態(tài)機，紅包的狀態(tài)推進
• 紅包查詢服務(wù)
• 主要承載紅包查詢功能，包括紅包詳情、紅包發(fā)送狀態(tài)、紅包領(lǐng)取狀態(tài)、紅包領(lǐng)取詳情、紅包補貼信息
• 紅包異步服務(wù)
• 主要承載紅包異步任務(wù)，保證狀態(tài)機的流轉(zhuǎn)，包括紅包的轉(zhuǎn)賬，紅包的退款，以及紅包補貼的狀態(tài)推進
• 紅包基礎(chǔ)服務(wù)
• 主要承載紅包各個系統(tǒng)的公共調(diào)用，例如對 DB，redis、tcc 的操作，公共常量和工具類，相當(dāng)于紅包的基礎(chǔ)工具包
• 紅包對賬服務(wù)
• 主要承載紅包和財經(jīng)的對賬邏輯，按天和財經(jīng)對賬

整體架構(gòu)

最后整個視頻紅包的系統(tǒng)架構(gòu)如圖所示

大流量補貼的發(fā)放處理

同步獎勵發(fā)放

在紅包補貼發(fā)放鏈路流程中，為了應(yīng)對春節(jié)的大流量，整個鏈路流程也經(jīng)歷過幾次方案的迭代。

在最初的方案設(shè)計中，我們是按照同步的補貼發(fā)放流程來處理的，上游鏈路調(diào)用紅包系統(tǒng)接口發(fā)券，發(fā)券成功后用戶感知到券發(fā)放成功，可以使用該券來發(fā)放紅包，最初方案的整體流程如下圖：

上面方案的一個問題是在春節(jié)活動期間，整個鏈路都需要能扛住活動期間的總流量，而且最終流量都會打到數(shù)據(jù)庫，而數(shù)據(jù)庫的資源在春節(jié)期間也是比較緊缺的。

異步獎勵發(fā)放

為了解決同步獎勵發(fā)放的問題，整體流程改為通過 MQ 進行削峰，從而降低下游的流量壓力，相當(dāng)于是從同步改為異步，用戶參與活動后會先下發(fā)一個加密 Token 給客戶端，用于客戶端的展示以及和服務(wù)端的交互處理?；顒赢惒桨l(fā)券方案如下圖

這樣解決了大流量的問題，但是相應(yīng)地引入了其他的問題，在最初方案中，用戶的紅包補貼都會先在紅包系統(tǒng)中落庫，后續(xù)用戶對補貼的查詢和核銷我們都能在紅包數(shù)據(jù)庫中找到對應(yīng)的記錄，但是在異步的方式中，整個補貼的入賬預(yù)估需要 10min，而用戶在 APP 界面感知到發(fā)券后可能馬上就會開始使用用補貼來發(fā)放視頻紅包，或者會去紅包掛件查看自己已經(jīng)領(lǐng)取的紅包補貼，而此時補貼還未在紅包系統(tǒng)中入賬。

最終方案

為了解決上面問題，我們對紅包補貼的視頻紅包發(fā)放和紅包補貼查詢的整個邏輯進行了修改，在用戶使用紅包補貼進行視頻紅包發(fā)放時，我們會先對該補貼進行一個入庫操作，入庫成功后才可以用這個補貼進行紅包發(fā)放。另外對于查詢接口，我們無法感知到所有補貼是否完全入賬，因此每次查詢時我們都需要去獎勵發(fā)放端查詢?nèi)康?Token 列表，同時我們還需要查詢出數(shù)據(jù)庫中用戶的補貼，對這兩部分?jǐn)?shù)據(jù)進行一次 merge 操作，才能得到全量的補貼列表。

在上面的流程中，為了解決 MQ 異步會有延遲的問題，我們在用戶進行請求時主動地進行入賬，而用戶主動的操作包括使用補貼發(fā)放紅包和查詢補貼，我們?yōu)槭裁粗辉谘a貼發(fā)放紅包時入賬而在查詢補貼時不入賬呢？因為用戶的查詢行為是一個高頻行為，同時涉及到批量的操作，在操作 DB 前我們無法感知該補貼是否入賬，所以會涉及到 DB 的批量處理，甚至用戶每次來查詢時我們都需要重復(fù)這個操作，會導(dǎo)致大量的 DB 資源浪費。而補貼的發(fā)放時入賬則是一個低頻的，單個補貼的操作，我們只需要在用戶核銷時入賬即可，這樣可以大量減輕數(shù)據(jù)庫的壓力，節(jié)省數(shù)據(jù)庫資源。

紅包領(lǐng)取方案的選型

在視頻紅包領(lǐng)取的技術(shù)方案中，我們也有一些方案的選擇和思考，這里和大家分享下。

悲觀鎖方案

方案一也是最常見的思路，在用戶領(lǐng)取時對數(shù)據(jù)庫的紅包進行加鎖，然后扣減金額，然后釋放鎖完成整個紅包領(lǐng)取。這個方案的優(yōu)點是清晰明了，但是這種方案的問題會導(dǎo)致多個用戶同時來領(lǐng)取紅包時，會造成數(shù)據(jù)庫行鎖的沖突，需要排隊等待，當(dāng)排隊請求過多時會造成數(shù)據(jù)庫鏈接的浪費，影響整體系統(tǒng)的性能。同時在上游長時間未收到反饋導(dǎo)致超時，用戶側(cè)可能會不停重試，導(dǎo)致整體數(shù)據(jù)庫鏈接被耗盡，從而導(dǎo)致系統(tǒng)崩潰。

紅包預(yù)拆分方案

方案一的問題是多個用同時領(lǐng)取會造成鎖沖突，解鎖鎖沖突可以通過拆分的方式，來將鎖化成更細的粒度，從而提高單個紅包的領(lǐng)取并發(fā)量。具體方案如下：

在方案二中，對發(fā)紅包的流程進行了一個改動，在發(fā)紅包時會對紅包進行一個預(yù)拆分的處理，將紅包拆成多個紅包，這樣就完成了鎖粒度的細化，在用戶領(lǐng)取紅包時從之前的爭搶單個紅包鎖變?yōu)楝F(xiàn)在多個紅包鎖分配。從而在領(lǐng)取紅包時問題就變?yōu)槿绾谓o用戶分配紅包，一種常用的思路是當(dāng)用戶請求領(lǐng)取紅包時，通過 redis 的自增方法來生成序列號，該序列號即對應(yīng)該領(lǐng)取那一個紅包。但是這種方式強依賴 redis,在 redis 網(wǎng)絡(luò)抖動或者 redis 服務(wù)異常時，需要降級到去查詢 DB 還未領(lǐng)取的紅包來獲取序列號，整體實現(xiàn)比較復(fù)雜。

最終方案

在視頻紅包的場景中，整個業(yè)務(wù)流程是用戶拍攝視頻發(fā)紅包，然后在視頻推薦 feed 流中刷到視頻時，才會觸發(fā)領(lǐng)取。相對于微信和飛書這種群聊場景，視頻紅包中同一個紅包的領(lǐng)取并發(fā)數(shù)并不會很高，因為用戶刷視頻的操作以及 feed 流本身就完成了流量的打散，所以對于視頻紅包來說，領(lǐng)取的并發(fā)數(shù)并不會很高。從業(yè)務(wù)的角度來看，在需求實現(xiàn)上，我們在用戶領(lǐng)取完成后需要能獲取到未領(lǐng)取紅包的個數(shù)信息下發(fā)給用戶展示，方案一獲取紅包庫存很方便，而方案二獲取庫存比較麻煩。另外從系統(tǒng)開發(fā)復(fù)雜度和容災(zāi)情況看，方案一相對來說是一個更合適的選擇。但是方案一中的風(fēng)險我們需要處理下。我們需要有其他的方式來保護 DB 資源，盡量減少鎖的沖突。具體方案如下：

• 紅包 redis 限流
• 為盡可能少的減少 DB 鎖沖突，首先會按照紅包單號進行限流，每次允許剩余紅包個數(shù)*1.5 的請求量通過。被限流返回特殊錯誤碼，前端最多輪訓(xùn) 10 次，在請求量過多的情況下通過這種方式來慢慢處理
• 內(nèi)存排隊
• 除了 redis 限流外，為了減少 DB 鎖，我們在領(lǐng)取流程中加個一個紅包內(nèi)存鎖，對于單個紅包，只有獲取到內(nèi)存鎖的請求才能繼續(xù)去請求 DB，從而將 DB 鎖的沖突遷移到內(nèi)存中提前處理，而內(nèi)存資源相對于 DB 資源來說是非常廉價的，在請求量過大時，我們可以水平擴容。
• 為了實現(xiàn)內(nèi)存鎖，我們進行了幾個改動。首先需要保證同一個紅包請求能打到同一個 tce 實例上，這里我們對網(wǎng)關(guān)層路由進行了調(diào)整，在網(wǎng)關(guān)層調(diào)用下游服務(wù)時，會按照紅包單號進行路由策略，保證同一單號的請求打到同一個實例上。另外我們在紅包系統(tǒng)的 core 服務(wù)中基于 channel 實現(xiàn)了一套內(nèi)存鎖，在領(lǐng)取完成后會釋放該紅包對應(yīng)的內(nèi)存鎖。另外為了防止鎖的內(nèi)存占用過大或者未及時釋放，我們起了一個定時任務(wù)去定期地處理。
• 轉(zhuǎn)賬異步化
• 從接口耗時來看，轉(zhuǎn)賬是一個耗時較長的操作，本身涉及和第三方支付機構(gòu)交互，會有跨機房請求，響應(yīng)延時較長，將轉(zhuǎn)賬異步化可以降低領(lǐng)取紅包接口的時延，提高服務(wù)性能和用戶體驗
• 另外從用戶感知來看，用戶更關(guān)注的是領(lǐng)取紅包的點擊開后是否領(lǐng)取成功，至于余額是否同步到賬用戶其實感知沒那么強烈，另外轉(zhuǎn)賬本身也是有一個轉(zhuǎn)賬中到轉(zhuǎn)賬成功的過程，將轉(zhuǎn)賬異步化對于用戶的感知基本沒有影響

穩(wěn)定性容災(zāi)

整個紅包系統(tǒng)的容災(zāi)我們主要從接口限流，業(yè)務(wù)降級和多重機制保證狀態(tài)機的推進這幾個方式來進行的，下面對這幾個方式分別介紹下：

接口限流

接口限流是一種常見的容災(zāi)方式，用于保護系統(tǒng)只處理承受范圍內(nèi)的請求，防止外部請求過大將系統(tǒng)打崩。在進行接口限流前，我們首先需要和上下游以及產(chǎn)品溝通得到一個預(yù)估的紅包發(fā)放和領(lǐng)取量，然后根據(jù)發(fā)放和領(lǐng)取量進行分模塊地全鏈路的大盤流量梳理，下面是當(dāng)時我們梳理的一個 b2c 全鏈路的請求量。

有個各個模塊的請求量后，匯總之后就可以得到各個接口，紅包系統(tǒng)各個服務(wù)以及下游依賴的各個服務(wù)的流量請求，這個時候再做限流就比較方便了。

業(yè)務(wù)降級

核心依賴降級

在春節(jié)活動期間，紅包系統(tǒng)整個鏈路依賴的服務(wù)有很多，這些下游的鏈路依賴可以分為核心依賴和非核心依賴，當(dāng)下游核心服務(wù)異常時，可能某一個鏈路就不可用，此時可以在 API 層直接降級返回一個比較友好的文案提示，等下游服務(wù)恢復(fù)后再放開。比如在 C2C 的紅包發(fā)送流程中，用戶需要完成支付才可以發(fā)紅包，如果財經(jīng)的支付流程異?；蛘咧Ц冻晒顟B(tài)長時間未完成，會造成用戶支付后紅包發(fā)送不成功，也會導(dǎo)致前端來不停的輪訓(xùn)查詢紅包狀態(tài)，導(dǎo)致請求量陡增，造成服務(wù)壓力，甚至影響 B2C 的紅包發(fā)放和查詢。此時可以通過接口降級的方式，將 C2C 的紅包發(fā)放降級返回，減少服務(wù)壓力，同時降低對其他業(yè)務(wù)邏輯的影響。

非核心依賴降級

除核心依賴外，紅包系統(tǒng)還有一些非核心的下游依賴，對于這些依賴，如果服務(wù)出現(xiàn)異常，我們可以降低用戶部分體驗的方式來保證服務(wù)的可用。比如在 4.2 中我們提到的，用戶在發(fā) B2C 紅包前需要先獲取所有可用的紅包補貼，我們會去獎勵發(fā)放端查詢到所有的 Token 列表，然后查詢我們自己的 DB，然后進行 merge 返回。如果獲取 Token 列表的接口異常時，我們可以降級只返回我們自己 DB 中的補貼數(shù)據(jù)，這樣可以保證用戶在這種情況下還可以進行紅包的發(fā)放，只影響部分補貼的展示，而不是影響整個紅包發(fā)送鏈路。

多重機制保證狀態(tài)機的推進

在紅包系統(tǒng)中，如果某個訂單長時間未到終態(tài)，比如用戶領(lǐng)取紅包后長時間未到賬，或者用戶 C2C 紅包未領(lǐng)取長時間未給用戶退款都有可能造成用戶的客訴。因此需要及時準(zhǔn)確地保證系統(tǒng)中各個訂單的狀態(tài)能推到終態(tài)。

這里我們有幾種方式去保證，首先是回調(diào)，在依賴方系統(tǒng)訂單處理完后會及時地通知給紅包系統(tǒng)，這種方式也是最及時的一種方式。但是只依賴回調(diào)可能會出現(xiàn)依賴方異?；蛘呔W(wǎng)絡(luò)抖動導(dǎo)致回調(diào)丟失，此時我們在紅包的各個階段都會給紅包系統(tǒng)發(fā)一個 mq，間隔一定的時間去消費 mq 主動查詢依賴方的訂單狀態(tài)進行更新。最后我們對每個狀態(tài)機都會有一個定時任務(wù)用于兜底，在定時任務(wù)多次執(zhí)行仍未到終態(tài)的會 lark 通知，及時人工介入發(fā)現(xiàn)問題。

資金安全保證

交易冪等

在編程中，冪等指任意多次執(zhí)行一個請求所產(chǎn)生的影響與一次執(zhí)行的影響相同。在資金安全中，通過訂單號來進行相應(yīng)的冪等邏輯處理可以防止資損的發(fā)生。具體來說在紅包系統(tǒng)中，在紅包的發(fā)放，領(lǐng)取和退款中，我們都通過訂單號唯一鍵來保證接口冪等。另外紅包系統(tǒng)的補貼發(fā)放接口是冪等的，外部同一個單號多次請求發(fā)放補貼，我們需要保證只會發(fā)一張券。

實現(xiàn)冪等的方案很多，包括有通過數(shù)據(jù)庫或者 redis 來實現(xiàn)冪等的。最可靠的就是通過數(shù)據(jù)庫的唯一鍵沖突來實現(xiàn)，但是這種方式在數(shù)據(jù)庫存在分片實例時會引入一些額外的問題。這里我們就補貼的發(fā)放來簡單介紹下，在業(yè)務(wù)系統(tǒng)的設(shè)計中，我們是按照 uid 分片的方式來建立業(yè)務(wù)的數(shù)據(jù)庫表，這就導(dǎo)致補貼的分片鍵是 uid，雖然我們也設(shè)置了紅包的補貼單號作為唯一鍵。但是其中存在一個風(fēng)險就是如果上游的系統(tǒng)調(diào)用補貼發(fā)放時，同一個外部單號更換了 uid，就可能會導(dǎo)致兩個請求分別打到不同的數(shù)據(jù)庫實例上，導(dǎo)致唯一索引失效，造成資損。為了解決這個問題，我們又額外的引入一個以補貼發(fā)放外部單號作為分片鍵的數(shù)據(jù)庫來解決這個風(fēng)險。

B2C 紅包核對

除了在開發(fā)過程的系統(tǒng)設(shè)計上進行相應(yīng)的資金安全考慮，我們還需要通過對賬的方式來校驗我們的系統(tǒng)是否有資金安全問題。

在 B2C 鏈路中，整個鏈路主要是從補貼發(fā)放到紅包領(lǐng)取，我們對這幾個鏈路的上下游的數(shù)據(jù)都進行相應(yīng)的小時計 hive 對賬。

C2C 紅包核對

在 C2C 鏈路中，整個主要從用戶發(fā)起支付，到用戶領(lǐng)取轉(zhuǎn)賬以及最后紅包過期退款。在支付，轉(zhuǎn)賬，退款這三個流程都需要進行相應(yīng)的核對。同時，還需要保證用戶的紅包發(fā)放金額大于等于紅包轉(zhuǎn)賬金額+紅包退款金額，這里大于等于是因為紅包從發(fā)放成功到退款成功整個周期會在 24h 以上，另外可能存在轉(zhuǎn)賬在途的這種訂導(dǎo)致會有多筆退款單，如果要求嚴(yán)格等于的話具體對賬時機沒法控制。

紅包系統(tǒng)的壓測

前面提到過，紅包系統(tǒng)的鏈路包含有多個接口，發(fā)領(lǐng)查等，需要模擬用戶的真實行為來進行壓測才能得到系統(tǒng)的真實性能。這里我們使用了壓測平臺的腳本壓測方式來進行壓測。

首先需要對整個壓測鏈路整個改造，和上下游溝通是否可以壓測，不能壓測的需要進行相應(yīng)的 mock 處理。另外對于存儲服務(wù)，數(shù)據(jù)庫，redis 和 mq 都要確保壓測標(biāo)的正確傳遞，否則可能會影響到線上。

改造完壓測鏈路后，需要構(gòu)造相應(yīng)的壓測腳本，對于 B2C 和 C2C 分為兩個腳本。

B2C 紅包鏈路壓測

上面是 B2C 壓測的整個鏈路，首先是補貼的發(fā)放，然后通過查詢補貼，通過補貼來發(fā)放紅包，為了模擬多人來領(lǐng)取的情況，我們起了多個 goroutinue 來并發(fā)的領(lǐng)取紅包。

C2C 紅包鏈路壓測

C2C 紅包因為涉及到支付相關(guān)的操作，整個鏈路又是另外一套流程，因此對于 C2C 也需要有一個單獨的腳本。在壓測流程中，因為涉及到外部系統(tǒng)的依賴，如果等待全鏈路 OK 時再一起壓測可能會導(dǎo)致一些未知的問題出現(xiàn)。因此我們需要自己壓測沒問題后再開始全鏈路一起壓測，在圖中和支付相關(guān)的藍色模塊我們都添加了相應(yīng)的 mock 開關(guān)，來控制壓測的結(jié)果。在 mock 開關(guān)打開時，會直接構(gòu)造一個結(jié)果返回，在 mock 開關(guān)關(guān)閉時，會正常地去請求財經(jīng)獲取結(jié)果。

后續(xù)規(guī)劃

服務(wù) Set 化

在前面提到的系統(tǒng)容災(zāi)中，如果紅包核心服務(wù)改掉，或者數(shù)據(jù)庫 DB 主機房掛掉，將影響所有的用戶，此時只能降級返回，整個系統(tǒng)無法快速切換和恢復(fù)。后續(xù)考慮將服務(wù)改為 set 化的架構(gòu)。將服務(wù) Server 和對應(yīng)的存儲劃分為一個單獨的 Set，每個 Set 只處理對應(yīng)劃分單元內(nèi)的流量，同時多個單元之間實現(xiàn)流量拆分和故障隔離，以及 Set 之間數(shù)據(jù)備份。這樣后續(xù)在某個單元異常時，可以及時將對應(yīng)單元的流量切到備份單元中。

加入我們

開放平臺錢包團隊為抖音開放平臺提供底層支付能力支持，目前業(yè)務(wù)在快速發(fā)展中，面臨各種復(fù)雜場景和技術(shù)挑戰(zhàn)，歡迎郵件聯(lián)系：wanghao.rock@bytedance.com 加入我們，一起做挑戰(zhàn)性的事！

好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡(luò)推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525  備注：發(fā)貨聯(lián)盟引流學(xué)習(xí)； 我拉你進直播課程學(xué)習(xí)群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術(shù)課程免費分享！