作者｜趙京木

字節(jié)跳動(dòng)開(kāi)放平臺(tái)-錢包團(tuán)隊(duì)整體負(fù)責(zé)字節(jié)系八端 2022 年春節(jié)活動(dòng)獎(jiǎng)勵(lì)鏈路的入賬、展示與使用，下文是對(duì)這段工作的介紹和總結(jié)，先整體介紹一下業(yè)務(wù)背景與技術(shù)架構(gòu)，然后說(shuō)明了各個(gè)難點(diǎn)的具體實(shí)現(xiàn)方案，最后進(jìn)行抽象總結(jié)，希望對(duì)后續(xù)的活動(dòng)起指導(dǎo)作用。

1. 背景&挑戰(zhàn)&目標(biāo)

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

(1)支持八端：2022 年字節(jié)系產(chǎn)品春節(jié)活動(dòng)需要支持八端 APP 產(chǎn)品(包含抖音/抖音火山/抖音極速版/西瓜/頭條/頭條極速版/番茄小說(shuō)/番茄暢聽(tīng))的獎(jiǎng)勵(lì)互通。用戶在上述任意一端都可以參與活動(dòng)，得到的獎(jiǎng)勵(lì)在其他端都可以提現(xiàn)與使用。

(2)玩法多變：主要有集卡、朋友頁(yè)紅包雨、紅包雨、集卡開(kāi)獎(jiǎng)與煙火大會(huì)等。

(3)多種獎(jiǎng)勵(lì)：獎(jiǎng)勵(lì)類型包含現(xiàn)金紅包、補(bǔ)貼視頻紅包、商業(yè)化廣告券、電商券、支付券、消費(fèi)金融券、保險(xiǎn)券、信用卡優(yōu)惠券、喜茶券、電影票券、dou+券、抖音文創(chuàng)券、頭像掛件等。

1.2 核心挑戰(zhàn)

(1)設(shè)計(jì)&實(shí)現(xiàn)八端獎(jiǎng)勵(lì)入賬與展示互通的大流量的方案，最高預(yù)估有 360w QPS 發(fā)獎(jiǎng)。

(2)多種發(fā)獎(jiǎng)勵(lì)的場(chǎng)景，玩法多變;獎(jiǎng)勵(lì)類型多，共 10 余種獎(jiǎng)勵(lì)。對(duì)接多個(gè)下游系統(tǒng)。

(3)從獎(jiǎng)勵(lì)系統(tǒng)穩(wěn)定性、用戶體驗(yàn)、資金安全與運(yùn)營(yíng)基礎(chǔ)能力全方位保障，確保活動(dòng)順利進(jìn)行 。

1.3 最終目標(biāo)

(1)獎(jiǎng)勵(lì)入賬：設(shè)計(jì)與實(shí)現(xiàn)八端獎(jiǎng)勵(lì)互通的獎(jiǎng)勵(lì)入賬系統(tǒng)，對(duì)接多個(gè)獎(jiǎng)勵(lì)下游系統(tǒng)，抹平不同獎(jiǎng)勵(lì)下游的差異，對(duì)上游屏蔽底層獎(jiǎng)勵(lì)入賬細(xì)節(jié)，設(shè)計(jì)統(tǒng)一的接口協(xié)議提供給業(yè)務(wù)上游。提供統(tǒng)一的錯(cuò)誤處理機(jī)制，入賬冪等能力和獎(jiǎng)勵(lì)預(yù)算控制。

(2)獎(jiǎng)勵(lì)展示/使用：設(shè)計(jì)與實(shí)現(xiàn)活動(dòng)錢包頁(yè)，支持在八端展示用戶所獲得的獎(jiǎng)勵(lì)，支持用戶查看、提現(xiàn)(現(xiàn)金)，使用卡券/掛件等能力。

(3)基礎(chǔ)能力：

【基礎(chǔ) sdk】提供查詢紅包余額、累計(jì)收入、用戶在春節(jié)活動(dòng)是否獲得過(guò)獎(jiǎng)勵(lì)等基礎(chǔ) sdk，供業(yè)務(wù)方查詢使用。

【預(yù)算控制】與上游獎(jiǎng)勵(lì)發(fā)放端算法策略打通，實(shí)現(xiàn)大流量卡券入賬的庫(kù)存控制能力，防止超發(fā)。

【提現(xiàn)控制】在除夕當(dāng)天多輪獎(jiǎng)勵(lì)發(fā)放后，提供用戶提現(xiàn)的灰度放量能力、提現(xiàn)時(shí)尚未入賬的處理能力。

【運(yùn)營(yíng)干預(yù)】活動(dòng)頁(yè)面靈活的運(yùn)營(yíng)配置能力，支持快速發(fā)布公告，及時(shí)觸達(dá)用戶。為應(yīng)對(duì)黑天鵝事件，支持批量卡券和紅包補(bǔ)發(fā)能力。

(4)穩(wěn)定性保障：在大流量的入賬場(chǎng)景下，保證錢包核心路徑穩(wěn)定性與完善，通過(guò)常用穩(wěn)定性保障手段如資源擴(kuò)容、限流、熔斷、降級(jí)、兜底、資源隔離等方式保證用戶獎(jiǎng)勵(lì)方向的核心體驗(yàn)。

(5)資金安全：在大流量的入賬場(chǎng)景下，通過(guò)冪等、對(duì)賬、監(jiān)控與報(bào)警等機(jī)制，保證資金安全，保證用戶資產(chǎn)應(yīng)發(fā)盡發(fā)，不少發(fā)。

(6)活動(dòng)隔離：實(shí)現(xiàn)內(nèi)部測(cè)試活動(dòng)、灰度放量活動(dòng)和正式春節(jié)活動(dòng)三個(gè)階段的獎(jiǎng)勵(lì)入賬與展示的數(shù)據(jù)隔離，不互相影響。

2. 產(chǎn)品需求介紹

用戶可以在任意一端參與字節(jié)的春節(jié)活動(dòng)獲取獎(jiǎng)勵(lì)，以抖音紅包雨現(xiàn)金紅包入賬場(chǎng)景為例，具體的業(yè)務(wù)流程如下：

登錄抖音 → 參與活動(dòng) → 活動(dòng)錢包頁(yè) → 點(diǎn)擊提現(xiàn)按鈕 → 進(jìn)入提現(xiàn)頁(yè)面 → 進(jìn)行提現(xiàn) → 提現(xiàn)結(jié)果頁(yè)，另外從錢包頁(yè)也可以進(jìn)入活動(dòng)錢包頁(yè)。

獎(jiǎng)勵(lì)發(fā)放核心場(chǎng)景：

• ?集卡?：集卡抽卡時(shí)發(fā)放各類卡券，集卡錦鯉還會(huì)發(fā)放大額現(xiàn)金紅包，集卡開(kāi)獎(jiǎng)時(shí)發(fā)放瓜分獎(jiǎng)金和優(yōu)惠券;
• 紅包雨：發(fā)紅包、卡券以及視頻補(bǔ)貼紅包，其中紅包和卡券最高分別 180w QPS;
• 煙火大會(huì)：發(fā)紅包、卡券以及頭像掛件。

3. 錢包資產(chǎn)中臺(tái)設(shè)計(jì)與實(shí)現(xiàn)

在 2022 年春節(jié)活動(dòng)中，UG 主要負(fù)責(zé)活動(dòng)的玩法實(shí)現(xiàn)，包含集卡、紅包雨以及煙火大會(huì)等具體的活動(dòng)相關(guān)業(yè)務(wù)邏輯和穩(wěn)定性保障。而錢包方向定位是大流量場(chǎng)景下實(shí)現(xiàn)獎(jiǎng)勵(lì)入賬、獎(jiǎng)勵(lì)展示、獎(jiǎng)勵(lì)使用與資金安全保障的相關(guān)任務(wù)。其中資產(chǎn)中臺(tái)負(fù)責(zé)獎(jiǎng)勵(lì)發(fā)放與獎(jiǎng)勵(lì)展示部分。

3.1 春節(jié)資產(chǎn)資產(chǎn)中臺(tái)總體架構(gòu)圖如下：

錢包資產(chǎn)中臺(tái)核心系統(tǒng)劃分如下：

資產(chǎn)訂單層：收斂八端獎(jiǎng)勵(lì)入賬鏈路，提供統(tǒng)一的接口協(xié)議對(duì)接上游活動(dòng)業(yè)務(wù)方如 UG、激勵(lì)中臺(tái)、視頻紅包等的獎(jiǎng)勵(lì)發(fā)放功能，同時(shí)對(duì)上游屏蔽對(duì)接獎(jiǎng)勵(lì)業(yè)務(wù)下游的邏輯處理，支持預(yù)算控制、補(bǔ)償、訂單號(hào)冪等。

活動(dòng)錢包 api 層：收斂八端獎(jiǎng)勵(lì)展示鏈路，同時(shí)支持大流量場(chǎng)景

3.2 資產(chǎn)訂單中心設(shè)計(jì)

核心發(fā)放模型：

說(shuō)明：

• 活動(dòng) ID 唯一區(qū)分一個(gè)活動(dòng)，本次春節(jié)分配了一個(gè)單獨(dú)的母活動(dòng) ID
• 場(chǎng)景 ID 和具體的一種獎(jiǎng)勵(lì)類型一一對(duì)應(yīng)，定義該場(chǎng)景下發(fā)獎(jiǎng)勵(lì)的唯一配置，場(chǎng)景 ID 可以配置的能力有：發(fā)獎(jiǎng)勵(lì)賬單文案;是否需要補(bǔ)償;限流配置;是否進(jìn)行庫(kù)存控制;是否要進(jìn)行對(duì)賬。提供可插拔的能力，供業(yè)務(wù)可選接入。

實(shí)現(xiàn)效果：

• 實(shí)現(xiàn)不同活動(dòng)之間的配置隔離
• 每個(gè)活動(dòng)的配置呈樹(shù)狀結(jié)構(gòu)，實(shí)現(xiàn)一個(gè)活動(dòng)發(fā)多種獎(jiǎng)勵(lì)，一種獎(jiǎng)勵(lì)發(fā)多種獎(jiǎng)勵(lì) ID
• 一種獎(jiǎng)勵(lì) ID 可以有多種分發(fā)場(chǎng)景，支持不同場(chǎng)景的個(gè)性化配置

訂單號(hào)設(shè)計(jì)：

資產(chǎn)訂單層支持訂單號(hào)維度的發(fā)獎(jiǎng)冪等，訂單號(hào)設(shè)計(jì)邏輯為${actID}_${scene_id}_${rain_id}_${award_type}_${statge}，從單號(hào)設(shè)計(jì)層面保證不超發(fā)，每個(gè)場(chǎng)景的獎(jiǎng)勵(lì)用戶最多只領(lǐng)一次。

4. 核心難點(diǎn)問(wèn)題解決

4.1 難點(diǎn)一：支持八端獎(jiǎng)勵(lì)數(shù)據(jù)互通

前文背景已經(jīng)介紹過(guò)了，參與 2022 年春節(jié)活動(dòng)一共有八個(gè)產(chǎn)品端，其中抖音系和頭條系 APP 是不同的賬號(hào)體系，所以不能通過(guò)用戶 ID 打通獎(jiǎng)勵(lì)互通。具體解決方案是字節(jié)賬號(hào)中臺(tái)打通了八端的賬號(hào)體系給每個(gè)用戶生成唯一的 actID(手機(jī)號(hào)優(yōu)先級(jí)最高，如果不同端登錄的手機(jī)號(hào)一樣，在不同端的 actID 是一致的)。錢包側(cè)基于字節(jié)賬號(hào)中臺(tái)提供的唯一 actID 基礎(chǔ)上，設(shè)計(jì)實(shí)現(xiàn)了支持八端獎(jiǎng)勵(lì)入賬、查看與使用的通用方案，即每個(gè)用戶的獎(jiǎng)勵(lì)數(shù)據(jù)是綁定在 actID 上的，入賬和查詢是通過(guò) actID 維度實(shí)現(xiàn)的，即可實(shí)現(xiàn)八端獎(jiǎng)勵(lì)互通。

示意圖如下：

4.2 難點(diǎn)二：高場(chǎng)景下的獎(jiǎng)勵(lì)入賬實(shí)現(xiàn)

每年的春節(jié)活動(dòng)，發(fā)現(xiàn)金紅包都是最關(guān)鍵的一環(huán)，今年也不例外。有幾個(gè)原因如下：

• 預(yù)估發(fā)現(xiàn)金紅包最大流量有 180w TPS。
• 現(xiàn)金紅包本身價(jià)值高，需要保證資金安全。
• 用戶對(duì)現(xiàn)金的敏感度很高，在保證用戶體驗(yàn)與功能完整性同時(shí)也要考慮成本問(wèn)題。

終上所述，發(fā)現(xiàn)金紅包面臨比較大的技術(shù)挑戰(zhàn)。

發(fā)紅包其實(shí)是一種交易行為，資金流走向是從公司成本出然后進(jìn)入個(gè)人賬戶。

(1)從技術(shù)方案上是要支持訂單號(hào)維度的冪等，同一訂單號(hào)多次請(qǐng)求只入賬一次。訂單號(hào)生成邏輯為${actID}_${scene_id}_${rain_id}_${award_type}_${statge}，從單號(hào)設(shè)計(jì)層面保證不超發(fā)。

(2)支持高并發(fā)，有以下 2 個(gè)傳統(tǒng)方案：

以上兩種傳統(tǒng)意義上的技術(shù)方案都有明顯的缺點(diǎn)，那么進(jìn)行思考，既能相對(duì)節(jié)約資源又能保證用戶體驗(yàn)的方案是什么?

最終采用的是紅包雨 token 方案，具體方案是使用異步入賬加較少量分布式存儲(chǔ)和較復(fù)雜方案來(lái)實(shí)現(xiàn)，下面具體介紹一下。

4.2.1 紅包雨 token 方案：

本次春節(jié)活動(dòng)在紅包雨/集卡開(kāi)獎(jiǎng)/煙火大會(huì)的活動(dòng)下有超大流量發(fā)紅包的場(chǎng)景，前文介紹過(guò)發(fā)獎(jiǎng) QPS 最高預(yù)估有 180w QPS，按照現(xiàn)有的賬戶入賬設(shè)計(jì)，需要大量存儲(chǔ)和計(jì)算資源支撐，根據(jù)預(yù)估發(fā)放紅包數(shù)/產(chǎn)品最大可接受發(fā)放時(shí)間，計(jì)算得到錢包實(shí)際入賬最低要支持的 TPS 為 30w，所以實(shí)際發(fā)放中有壓?jiǎn)蔚倪^(guò)程。

設(shè)計(jì)目標(biāo)：

在活動(dòng)預(yù)估給用戶發(fā)放(180w)與實(shí)際入賬(30w)有很大 gap 的情況下，保證用戶的核心體驗(yàn)。用戶在前端頁(yè)面查看與使用過(guò)當(dāng)中不能感知壓?jiǎn)蔚倪^(guò)程，即查看與使用體驗(yàn)不能受到影響，相關(guān)展示的數(shù)據(jù)包含余額，累計(jì)收入與紅包流水，使用包含提現(xiàn)等。

具體設(shè)計(jì)方案：

我們?cè)诖罅髁繄?chǎng)景下每次給用戶發(fā)紅包會(huì)生成一個(gè)加密 token(使用非對(duì)稱加密，包含發(fā)紅包的元信息：紅包金額，actID，與發(fā)放時(shí)間等)，分別存儲(chǔ)在客戶端和服務(wù)端(容災(zāi)互備)，每個(gè)用戶有個(gè) token 列表。每次發(fā)紅包的時(shí)候會(huì)在 Redis 里記錄該 token 的入賬狀態(tài)，然后用戶在活動(dòng)錢包頁(yè)看到的現(xiàn)金紅包流水、余額等數(shù)據(jù)，是合并已入賬紅包列表+token 列表-已入賬/入賬中 token 列表的結(jié)果。同時(shí)為保證用戶提現(xiàn)體驗(yàn)不感知紅包壓?jiǎn)瘟鞒?，在進(jìn)入提現(xiàn)頁(yè)或者點(diǎn)擊提現(xiàn)時(shí)將未入賬的 token 列表進(jìn)行強(qiáng)制入賬，保證用戶提現(xiàn)時(shí)賬戶的余額為應(yīng)入賬總金額，不 block 用戶提現(xiàn)流程。

示意圖如下：

token 數(shù)據(jù)結(jié)構(gòu)：

token 使用的是 pb 格式，經(jīng)單測(cè)驗(yàn)證存儲(chǔ)消耗實(shí)際比使用 json 少了一倍，節(jié)約請(qǐng)求網(wǎng)絡(luò)的帶寬和存儲(chǔ)成本;同時(shí)序列化與反序列化消耗 cpu 也有降低。

// 紅包雨token結(jié)構(gòu)
type RedPacketToken struct {
   AppID      int64  `protobuf: varint,1,opt  json: AppID,omitempty ` // 端ID
   ActID     int64  `protobuf: varint,2,opt  json: UserID,omitempty ` // ActID
   ActivityID string `protobuf: bytes,3,opt  json: ActivityID,omitempty ` // 活動(dòng)ID
   SceneID    string `protobuf: bytes,4,opt  json: SceneID,omitempty ` // 場(chǎng)景ID
   Amount     int64  `protobuf: varint,5,opt  json: Amount,omitempty ` // 紅包金額
   OutTradeNo string `protobuf: bytes,6,opt  json: OutTradeNo,omitempty ` // 訂單號(hào)
   OpenTime   int64  `protobuf: varint,7,opt  json: OpenTime,omitempty ` // 開(kāi)獎(jiǎng)時(shí)間
   RainID     int32  `protobuf: varint,8,opt,name=rainID  json: rainID,omitempty ` // 紅包雨ID
   Status     int64  `protobuf: varint,9,opt,name=status  json: status,omitempty ` //入賬狀態(tài)
}

token 狀態(tài)機(jī)流轉(zhuǎn)：

在調(diào)用賬戶真正入賬之前會(huì)置為處理中(2)狀態(tài)，調(diào)用賬戶成功為成功(8)狀態(tài)，發(fā)紅包沒(méi)有失敗的情況，后續(xù)都是可以重試成功的。

token 安全性保障：

采用非對(duì)稱加密算法來(lái)保障存儲(chǔ)在的客戶端盡可能不被破解，其中加密算法為秘密倉(cāng)庫(kù)，限制其他人訪問(wèn)。同時(shí)考慮極端情況下如果 token 加密算法被黑產(chǎn)破譯，可監(jiān)控報(bào)警發(fā)現(xiàn)，可降級(jí)。

4.2.2 活動(dòng)錢包頁(yè)展示紅包流水

需求背景：

活動(dòng)錢包頁(yè)展示的紅包流水是現(xiàn)金紅包入賬流水、提現(xiàn)流水、c2c 紅包流水三個(gè)數(shù)據(jù)源的合并，按照創(chuàng)建時(shí)間倒敘排列，需要支持分頁(yè)，可降級(jí)，保證用戶體驗(yàn)不感知發(fā)現(xiàn)金紅包壓?jiǎn)芜^(guò)程。

4.3 難點(diǎn)三：發(fā)獎(jiǎng)勵(lì)鏈路依賴多的穩(wěn)定性保障

發(fā)紅包流程降級(jí)示意圖如下：

根據(jù)歷史經(jīng)驗(yàn)，實(shí)現(xiàn)的功能越復(fù)雜，依賴會(huì)變多，對(duì)應(yīng)的穩(wěn)定性風(fēng)險(xiǎn)就越高，那么如何保證高依賴的系統(tǒng)穩(wěn)定性呢?

解決方案：

現(xiàn)金紅包入賬最基礎(chǔ)要保障的功能是將用戶得到的紅包進(jìn)行入賬，同時(shí)支持冪等與預(yù)算控制(避免超發(fā))，紅包賬戶的冪等設(shè)計(jì)強(qiáng)依賴數(shù)據(jù)庫(kù)保持事務(wù)一致性。但是如果極端情況發(fā)生，中間的鏈路可能會(huì)出現(xiàn)問(wèn)題，如果是弱依賴需要支持降級(jí)掉，不影響發(fā)放主流程。錢包方向發(fā)紅包最短路徑為依賴服務(wù)實(shí)例計(jì)算資源和 MySQL 存儲(chǔ)資源實(shí)現(xiàn)現(xiàn)金紅包入賬。

發(fā)紅包強(qiáng)弱依賴梳理圖示：

4.4 難點(diǎn)四：大流量發(fā)卡券預(yù)算控制

需求背景：

春節(jié)活動(dòng)除夕晚上 7 點(diǎn)半會(huì)開(kāi)始煙火大會(huì)，是大流量集中發(fā)券的一個(gè)場(chǎng)景，錢包側(cè)與算法策略配合進(jìn)行卡券發(fā)放庫(kù)存控制，防止超發(fā)。

具體實(shí)現(xiàn)：

(1)錢包資產(chǎn)中臺(tái)維護(hù)每個(gè)卡券模板 ID 的消耗發(fā)放量。

(2)每次卡券發(fā)放前算法策略會(huì)讀取錢包 sdk 獲取該卡券模板 ID 的消耗量以及總庫(kù)存數(shù)。同時(shí)會(huì)設(shè)置一個(gè)閾值，如果卡券剩余量小于 10%后不發(fā)這個(gè)券(使用兜底券或者祝福語(yǔ)進(jìn)行兜底)。

(3) 同時(shí)錢包資產(chǎn)中臺(tái)方向在發(fā)券流程累計(jì)每個(gè)券模板 ID 的消耗量(使用 Redis incr 命令原子累加消耗量)，然后與總活動(dòng)庫(kù)存進(jìn)行比對(duì)，如果消耗量大于總庫(kù)存數(shù)則拒絕掉，防止超發(fā)，也是一個(gè)兜底流程。

具體流程圖：

優(yōu)化方向：

(1)大流量下使用 Redis 計(jì)數(shù)，單 key 會(huì)存在熱 key 問(wèn)題，需要拆分 key 來(lái)解決。

(2)大流量場(chǎng)景下操作 Redis 會(huì)存在超時(shí)問(wèn)題，返回上游處理中，上游繼續(xù)重試發(fā)券會(huì)多消耗庫(kù)存少發(fā)，本次春節(jié)活動(dòng)實(shí)際活動(dòng)庫(kù)存在預(yù)估庫(kù)存基礎(chǔ)上加了 5%的量級(jí)來(lái)緩解超時(shí)帶來(lái)的少發(fā)問(wèn)題。

4.5 難點(diǎn)五：高 QPS 場(chǎng)景下的熱 key 的讀取和寫入穩(wěn)定性保障

需求背景：

在除夕晚上 7 點(diǎn)半開(kāi)始會(huì)開(kāi)始煙火大會(huì)活動(dòng)，展示所有紅包雨與煙火大會(huì)紅包的實(shí)時(shí)累計(jì)發(fā)放總額，最大流量預(yù)估讀取有 180wQPS，寫入 30wQPS。

這是典型的超大流量，熱點(diǎn) key、更新延遲不敏感，非數(shù)據(jù)強(qiáng)一致性場(chǎng)景(數(shù)字是一直累加)，同時(shí)要做好容災(zāi)降級(jí)處理，最后實(shí)際活動(dòng)展示的金額與產(chǎn)品預(yù)計(jì)發(fā)放數(shù)值誤差小于 1%。

4.5.1 方案一

提供 sdk 接入方式，復(fù)用了主會(huì)場(chǎng)機(jī)器實(shí)例的資源。高 QPS 下的讀取和寫入單 key，比較容易想到的是使用 Redis 分布式緩存來(lái)進(jìn)行實(shí)現(xiàn)，但是單 key 讀取和寫入的會(huì)打到一個(gè)實(shí)例上，壓測(cè)過(guò)單實(shí)例的瓶頸為 3w QPS。所以做的一個(gè)優(yōu)化是拆分多個(gè) key，然后用本地緩存兜底。

具體寫入流程：

設(shè)計(jì)拆分 100 個(gè) key，每次發(fā)紅包根據(jù)請(qǐng)求的 actID%100 使用 incr 命令累加該數(shù)字，因?yàn)椴荒鼙ＷC冪等性，所以超時(shí)不重試。

讀取流程：

與寫入流程類似，優(yōu)先讀取本地緩存，如果本地緩存值為為 0，那么去讀取各個(gè) Redis 的 key 值累加到一起，進(jìn)行返回。

問(wèn)題：

(1)拆分 100 個(gè) key 會(huì)出現(xiàn)讀擴(kuò)散的問(wèn)題，需要申請(qǐng)較多 Redis 資源，存儲(chǔ)成本比較高。而且可能存在讀取超時(shí)問(wèn)題，不能保證一次讀取所有 key 都讀取成功，故返回的結(jié)果可能會(huì)較上一次有減少。

(2)容災(zāi)方案方面，如果申請(qǐng)備份 Redis，也需要較多的存儲(chǔ)資源，需要的額外存儲(chǔ)成本。

4.5.2 方案二

設(shè)計(jì)思路：

在方案一實(shí)現(xiàn)的基礎(chǔ)上進(jìn)行優(yōu)化，并且要考慮數(shù)字不斷累加、節(jié)約成本與實(shí)現(xiàn)容災(zāi)方案。在寫場(chǎng)景，通過(guò)本地緩存進(jìn)行合并寫請(qǐng)求進(jìn)行原子性累加，讀場(chǎng)景返回本地緩存的值，減少額外的存儲(chǔ)資源占用。使用 Redis 實(shí)現(xiàn)中心化存儲(chǔ)，最終大家讀到的值都是一樣的。

具體設(shè)計(jì)方案：

每個(gè) docker 實(shí)例啟動(dòng)時(shí)都會(huì)執(zhí)行定時(shí)任務(wù)，分為讀 Redis 任務(wù)和寫 Redis 任務(wù)。

讀取流程：

• 本地的定時(shí)任務(wù)每秒執(zhí)行一次，讀取 Redis 單 key 的值，如果獲取到的值大于本地緩存那么更新本地緩存的值。
• 對(duì)外暴露的 sdk 直接返回本地緩存的值即可。
• 有個(gè)問(wèn)題需要注意下，每次實(shí)例啟動(dòng)第一秒內(nèi)是沒(méi)有數(shù)據(jù)的，所以會(huì)阻塞讀，等有數(shù)據(jù)再返回。

寫入流程：

• 因?yàn)樽x取都是讀取本地緩存(本地緩存不過(guò)期)，所以處理好并發(fā)情況下的寫即可。
• 本地緩存寫變量使用 go 的 atomic.AddInt64 支持原子性累加本地寫緩存的值。
• 每次執(zhí)行更新 Redis 的定時(shí)任務(wù)，先將本地寫緩存復(fù)制到 amount 變量，然后再將本地寫緩存原子性減去 amount 的值，最后將 amount 的值 incr 到 Redis 單 key 上，實(shí)現(xiàn) Redis 的單 key 的值一直累加。
• 容災(zāi)方案是使用備份 Redis 集群，寫入時(shí)進(jìn)行雙寫，一旦主機(jī)群掛掉，設(shè)計(jì)了一個(gè)配置開(kāi)關(guān)支持讀取備份 Redis。兩個(gè) Redis 集群的數(shù)據(jù)一致性，通過(guò)定時(shí)任務(wù)兜底實(shí)現(xiàn)。

本方案調(diào)用 Redis 的流量是跟實(shí)例數(shù)成正比，經(jīng)調(diào)研讀取側(cè)的服務(wù)為主會(huì)場(chǎng)實(shí)例數(shù) 2 萬(wàn)個(gè)，寫入側(cè)服務(wù)為資產(chǎn)中臺(tái)實(shí)例數(shù) 8 千個(gè)，所以實(shí)際 Redis 要支持的 QPS 為 2.8 萬(wàn)/定時(shí)任務(wù)執(zhí)行間隔(單位為 s)，經(jīng)壓測(cè)驗(yàn)證 Redis 單實(shí)例可以支持單 key2 萬(wàn) get，8k incr 的操作，所以設(shè)置定時(shí)任務(wù)的執(zhí)行時(shí)間間隔是 1s，如果實(shí)例數(shù)更多可以考慮延長(zhǎng)執(zhí)行時(shí)間間隔。

具體寫入流程圖如下：

4.5.3 方案對(duì)比

結(jié)論：

從實(shí)現(xiàn)效果，資源成本和容災(zāi)等方面考慮，最終選擇了方案二上線。

4.6 難點(diǎn)六：進(jìn)行母活動(dòng)與子活動(dòng)的平滑切換

需求背景：

為了保證本次春節(jié)活動(dòng)的最終上線效果和交付質(zhì)量，實(shí)際上分了三個(gè)階段進(jìn)行的。

(1)第一階段是內(nèi)部人員測(cè)試階段。

(2)第二個(gè)階段是外部演練階段，圈定部分外部用戶進(jìn)行春節(jié)活動(dòng)功能的驗(yàn)證(灰度放量)，也是發(fā)現(xiàn)暴露問(wèn)題以及驗(yàn)證對(duì)應(yīng)解決機(jī)制最有效的手段，影響面可控。

(3)第三個(gè)階段是正式春節(jié)活動(dòng)。

而產(chǎn)品的需求是這三個(gè)階段是分別獨(dú)立的階段，包含用戶獲得獎(jiǎng)勵(lì)、展示與使用獎(jiǎng)勵(lì)都是隔離的。

技術(shù)挑戰(zhàn)：

有多個(gè)上游調(diào)用錢包發(fā)獎(jiǎng)勵(lì)，同時(shí)錢包有多個(gè)獎(jiǎng)勵(lì)業(yè)務(wù)下游，所以大家一起改本身溝通成本較高，配置出錯(cuò)的概率就比較大，而且不能同步改，會(huì)有較大的技術(shù)安全隱患。

設(shè)計(jì)思路:

作為獎(jiǎng)勵(lì)入賬的唯一入口，錢包資產(chǎn)中臺(tái)收斂了整個(gè)活動(dòng)配置切換的實(shí)現(xiàn)。設(shè)計(jì)出母活動(dòng)和子活動(dòng)的分層配置，上游請(qǐng)求參數(shù)統(tǒng)一傳母活動(dòng) ID 代表春節(jié)活動(dòng)，錢包資產(chǎn)中臺(tái)根據(jù)請(qǐng)求時(shí)間決定采用哪個(gè)子活動(dòng)配置進(jìn)行發(fā)獎(jiǎng)，以此來(lái)實(shí)現(xiàn)不同時(shí)間段不同活動(dòng)的產(chǎn)品需求。降低了溝通成本，減少了配置出錯(cuò)的概率，并且可以同步切換，較大地提升了研發(fā)與測(cè)試人效。

示意圖：

4.7 難點(diǎn)七：大流量場(chǎng)景下資金安全保障

錢包方向在本次春節(jié)活動(dòng)期間做了三件事情來(lái)保障大流量大預(yù)算的現(xiàn)金紅包發(fā)放的資金安全：

1. 現(xiàn)金紅包發(fā)放整體預(yù)算控制的攔截
2. 單筆現(xiàn)金紅包發(fā)放金額上限的攔截
3. 大流量發(fā)紅包場(chǎng)景的資金對(duì)賬

• 小時(shí)級(jí)別對(duì)賬：支持紅包雨/集卡/煙火紅包發(fā)放 h+1 小時(shí)級(jí)對(duì)賬，并針對(duì)部分場(chǎng)景設(shè)置兜底 h+2 核對(duì)。
• 準(zhǔn)實(shí)時(shí)對(duì)賬：紅包雨已入賬的紅包數(shù)據(jù)反查錢包資產(chǎn)中臺(tái)和活動(dòng)側(cè)做準(zhǔn)實(shí)時(shí)對(duì)賬

多維度核對(duì)示意圖：

準(zhǔn)實(shí)時(shí)對(duì)賬流程圖：

說(shuō)明：

準(zhǔn)實(shí)時(shí)對(duì)賬監(jiān)控和報(bào)警可以及時(shí)發(fā)現(xiàn)是否異常入賬情況，如果報(bào)警發(fā)現(xiàn)會(huì)有緊急預(yù)案處理。

5. 通用模式抽象

在經(jīng)歷過(guò)春節(jié)超大流量活動(dòng)后的設(shè)計(jì)與實(shí)現(xiàn)后，有一些總結(jié)和經(jīng)驗(yàn)與大家一起分享一下。

5.1 容災(zāi)降級(jí)層面

大流量場(chǎng)景，為了保證活動(dòng)最終上線效果，容災(zāi)是一定要做好的。參考業(yè)界通用實(shí)現(xiàn)方案，如降級(jí)、限流、熔斷、資源隔離，根據(jù)預(yù)估活動(dòng)參與人數(shù)和效果進(jìn)行使用存儲(chǔ)預(yù)估等。

5.1.1 限流層面

(1)限流方面應(yīng)用了 api 層 nginx 入流量限流，分布式入流量限流，分布式出流量限流。這幾個(gè)限流器都是字節(jié)跳動(dòng)公司層面公共的中間件，經(jīng)過(guò)大流量的驗(yàn)證。

(2)首先進(jìn)行了實(shí)際單實(shí)例壓測(cè)，根據(jù)單實(shí)例扛住的流量與本次春節(jié)活動(dòng)預(yù)估流量打到該服務(wù)的流量進(jìn)行擴(kuò)容，并結(jié)合下游能抗住的情況，在 tlb 入流量、入流量限流以及出流量限流分別做好了詳細(xì)完整的配置并同。

限流目標(biāo)：

保證自身服務(wù)穩(wěn)定性，防止外部預(yù)期外流量把本身服務(wù)打垮，防止造成雪崩效應(yīng)，保證核心業(yè)務(wù)和用戶核心體驗(yàn)。

簡(jiǎn)單集群限流是實(shí)例維度的限流，每個(gè)實(shí)例限流的 QPS=總配置限流 QPS/實(shí)例數(shù)，對(duì)于多機(jī)器低 QPS 可能會(huì)有不準(zhǔn)的情況，要經(jīng)過(guò)實(shí)際壓測(cè)并且及時(shí)調(diào)整配置值。

對(duì)于分布式入流量和出流量限流，兩種使用方式如下，每種方式都支持高低 QPS，區(qū)別只是 SDK 使用方式和功能不同。一般低 QPS 精度要求高，采用 redis 計(jì)數(shù)方式，使用方提供自己的 redis 集群。高 QPS 精度要求低，退化為總 QPS/tce 實(shí)例數(shù)的單實(shí)例限流。

5.1.2 降級(jí)層面

對(duì)于高流量場(chǎng)景，每個(gè)核心功能都要有對(duì)應(yīng)的降級(jí)方案來(lái)保證突發(fā)情況核心鏈路的穩(wěn)定性。

(1)本次春節(jié)獎(jiǎng)勵(lì)入賬與活動(dòng)活動(dòng)錢包頁(yè)方向做好了充分的操作預(yù)案，一共有 26 個(gè)降級(jí)開(kāi)關(guān)，關(guān)鍵時(shí)刻棄車保帥，防止有單點(diǎn)問(wèn)題影響核心鏈路。

(2)以發(fā)現(xiàn)金紅包鏈路舉例，錢包方向最后完全降級(jí)的方案是只依賴 docker 和 MySQL，其他依賴都是可以降級(jí)掉的，MySQL 主有問(wèn)題可以緊急聯(lián)系切主，雖說(shuō)最后一個(gè)都沒(méi)用上，但是前提要設(shè)計(jì)好保證活動(dòng)的萬(wàn)無(wú)一失。

5.1.3 資源隔離層面

(1)提升開(kāi)發(fā)效率不重復(fù)造輪子。因?yàn)殄X包資產(chǎn)中臺(tái)也日常支持抖音資產(chǎn)發(fā)放的需求，本次春節(jié)活動(dòng)也復(fù)用了現(xiàn)有的接口和代碼流程支持發(fā)獎(jiǎng)。

(2)同時(shí)針對(duì)本次春節(jié)活動(dòng)，服務(wù)層面做了集群隔離，創(chuàng)建專用活動(dòng)集群，底層存儲(chǔ)資源隔離，活動(dòng)流量和常規(guī)流量互不影響。

5.1.4 存儲(chǔ)預(yù)估

(1)不但要考慮和驗(yàn)證了 Redis 或者 MySQL 存儲(chǔ)能抗住對(duì)應(yīng)的流量，同時(shí)也要按照實(shí)際的獲取參與和發(fā)放數(shù)據(jù)等預(yù)估存儲(chǔ)資源是否足夠。

(2)對(duì)于字節(jié)跳動(dòng)公司的 Redis 組件來(lái)講，可以進(jìn)行垂直擴(kuò)容(每個(gè)實(shí)例增加存儲(chǔ)，最大 10G)，也可以進(jìn)行水平擴(kuò)容(單機(jī)房上限是 500 個(gè)實(shí)例)，因?yàn)?Redis 是三機(jī)房同步的，所以計(jì)算存儲(chǔ)時(shí)只考慮一個(gè)機(jī)房的存儲(chǔ)上限即可。要留足 buffer，因?yàn)樗綌U(kuò)容是很慢的一個(gè)過(guò)程，突發(fā)情況遇到存儲(chǔ)資源不足只能通過(guò)配置開(kāi)關(guān)提前下掉依賴存儲(chǔ)，需要提前設(shè)計(jì)好。

5.1.5 壓測(cè)層面

本次春節(jié)活動(dòng)，錢包獎(jiǎng)勵(lì)入賬和活動(dòng)錢包頁(yè)做了充分的全鏈路壓測(cè)驗(yàn)證，下面是一些經(jīng)驗(yàn)總結(jié)。

在壓測(cè)前要建立好壓測(cè)整條鏈路的監(jiān)控大盤，在壓測(cè)過(guò)程當(dāng)中及時(shí)和方便的發(fā)現(xiàn)問(wèn)題。

對(duì)于 MySQL 數(shù)據(jù)庫(kù)，在紅包雨等大流量正式活動(dòng)開(kāi)始前，進(jìn)行小流量壓測(cè)預(yù)熱數(shù)據(jù)庫(kù)，峰值流量前提前建鏈，減少正式活動(dòng)時(shí)的大量建鏈耗時(shí)，保證發(fā)紅包鏈路數(shù)據(jù)庫(kù)層面的穩(wěn)定性。

壓測(cè)過(guò)程當(dāng)中一定要傳壓測(cè)標(biāo)，支持全鏈路識(shí)別壓測(cè)流量做特殊邏輯處理，與線上正常業(yè)務(wù)互不干擾。

針對(duì)壓測(cè)流量不做特殊處理，壓測(cè)流量處理流程保持和線上流量一致。

壓測(cè)中要驗(yàn)證計(jì)算資源與存儲(chǔ)資源是否能抗住預(yù)估流量

• 梳理好壓測(cè)計(jì)劃，基于歷史經(jīng)驗(yàn)，設(shè)置合理初始流量，漸進(jìn)提升壓測(cè)流量，實(shí)時(shí)觀察各項(xiàng)壓測(cè)指標(biāo)。
• 存儲(chǔ)資源壓測(cè)數(shù)據(jù)要與線上數(shù)據(jù)隔離，對(duì)于 MySQL 和 Bytekv 這種來(lái)講是建壓測(cè)表，對(duì)于 Redis 和 Abase 這種來(lái)講是壓測(cè) key 在線上 key 基礎(chǔ)加一下壓測(cè)前綴標(biāo)識(shí) 。
• 壓測(cè)數(shù)據(jù)要及時(shí)清理，Redis 和 Abase 這種加短時(shí)間的過(guò)期時(shí)間，過(guò)期機(jī)制處理比較方便，如果忘記設(shè)置過(guò)期時(shí)間，可以根據(jù)寫腳本識(shí)別壓測(cè)標(biāo)前綴去刪除。

壓測(cè)后也要關(guān)注存儲(chǔ)資源各項(xiàng)指標(biāo)是否符合預(yù)期。

5.2 微服務(wù)思考

在日常技術(shù)設(shè)計(jì)中，大家都會(huì)遵守微服務(wù)設(shè)計(jì)原則和規(guī)范，根據(jù)系統(tǒng)職責(zé)和核心數(shù)據(jù)模型拆分不同模塊，提升開(kāi)發(fā)迭代效率并不互相影響。但是微服務(wù)也有它的弊端，對(duì)于超大流量的場(chǎng)景功能也比較復(fù)雜，會(huì)經(jīng)過(guò)多個(gè)鏈路，這樣是極其消耗計(jì)算資源的。本次春節(jié)活動(dòng)資產(chǎn)中臺(tái)提供了 sdk 包代替 rpc 進(jìn)行微服務(wù)鏈路聚合對(duì)外提供基礎(chǔ)能力，如查詢余額、判斷用戶是否獲取過(guò)獎(jiǎng)勵(lì)，強(qiáng)制入賬等功能。訪問(wèn)流量最高上千萬(wàn)，與使用微服務(wù)架構(gòu)對(duì)比節(jié)約了上萬(wàn)核 CPU 的計(jì)算資源。

6. 系統(tǒng)的未來(lái)演進(jìn)方向

• 梳理上下游需求和痛點(diǎn)，優(yōu)化資產(chǎn)中臺(tái)設(shè)計(jì)實(shí)現(xiàn)，完善基礎(chǔ)能力，優(yōu)化服務(wù)架構(gòu)，提供一站式服務(wù)，讓接入活動(dòng)方可以更專注進(jìn)行活動(dòng)業(yè)務(wù)邏輯的研發(fā)工作。
• 加強(qiáng)實(shí)時(shí)和離線數(shù)據(jù)看板能力建設(shè)，讓獎(jiǎng)勵(lì)發(fā)放數(shù)據(jù)展示的更清晰更準(zhǔn)確。
• 加強(qiáng)配置化和文檔建設(shè)，對(duì)內(nèi)減少對(duì)接活動(dòng)的對(duì)接成本，對(duì)外提升活動(dòng)業(yè)務(wù)方接入效率。