作者｜趙京木
字節跳動開放平臺-錢包團隊整體負責字節系八端 2022 年春節活動獎勵鏈路的入賬、展示與使用，下文是對這段工作的介紹和總結，先整體介紹一下業務背景與技術架構，然后說明了各個難點的具體實現方案，最后進行抽象總結，希望對后續的活動起指導作用。
1. 背景&挑戰&目標
1.1 業務背景
(1)支持八端：2022 年字節系產品春節活動需要支持八端 APP 產品(包含抖音/抖音火山/抖音極速版/西瓜/頭條/頭條極速版/番茄小說/番茄暢聽)的獎勵互通。用戶在上述任意一端都可以參與活動，得到的獎勵在其他端都可以提現與使用。
(2)玩法多變：主要有集卡、朋友頁紅包雨、紅包雨、集卡開獎與煙火大會等。
(3)多種獎勵：獎勵類型包含現金紅包、補貼視頻紅包、商業化廣告券、電商券、支付券、消費金融券、保險券、信用卡優惠券、喜茶券、電影票券、dou+券、抖音文創券、頭像掛件等。
1.2 核心挑戰
(1)設計&實現八端獎勵入賬與展示互通的大流量的方案，最高預估有 360w QPS 發獎。
(2)多種發獎勵的場景，玩法多變;獎勵類型多，共 10 余種獎勵。對接多個下游系統。
(3)從獎勵系統穩定性、用戶體驗、資金安全與運營基礎能力全方位保障，確保活動順利進行 。
1.3 最終目標
(1)獎勵入賬：設計與實現八端獎勵互通的獎勵入賬系統，對接多個獎勵下游系統，抹平不同獎勵下游的差異，對上游屏蔽底層獎勵入賬細節，設計統一的接口協議提供給業務上游。提供統一的錯誤處理機制，入賬冪等能力和獎勵預算控制。
(2)獎勵展示/使用：設計與實現活動錢包頁，支持在八端展示用戶所獲得的獎勵，支持用戶查看、提現(現金)，使用卡券/掛件等能力。
(3)基礎能力：
【基礎 sdk】提供查詢紅包余額、累計收入、用戶在春節活動是否獲得過獎勵等基礎 sdk，供業務方查詢使用。
【預算控制】與上游獎勵發放端算法策略打通，實現大流量卡券入賬的庫存控制能力，防止超發。
【提現控制】在除夕當天多輪獎勵發放后，提供用戶提現的灰度放量能力、提現時尚未入賬的處理能力。
【運營干預】活動頁面靈活的運營配置能力，支持快速發布公告，及時觸達用戶。為應對黑天鵝事件，支持批量卡券和紅包補發能力。
(4)穩定性保障：在大流量的入賬場景下，保證錢包核心路徑穩定性與完善，通過常用穩定性保障手段如資源擴容、限流、熔斷、降級、兜底、資源隔離等方式保證用戶獎勵方向的核心體驗。
(5)資金安全：在大流量的入賬場景下，通過冪等、對賬、監控與報警等機制，保證資金安全，保證用戶資產應發盡發，不少發。
(6)活動隔離：實現內部測試活動、灰度放量活動和正式春節活動三個階段的獎勵入賬與展示的數據隔離，不互相影響。
2. 產品需求介紹
用戶可以在任意一端參與字節的春節活動獲取獎勵，以抖音紅包雨現金紅包入賬場景為例，具體的業務流程如下：
登錄抖音 → 參與活動 → 活動錢包頁 → 點擊提現按鈕 → 進入提現頁面 → 進行提現 → 提現結果頁，另外從錢包頁也可以進入活動錢包頁。
獎勵發放核心場景：
- ?集卡?：集卡抽卡時發放各類卡券，集卡錦鯉還會發放大額現金紅包，集卡開獎時發放瓜分獎金和優惠券;
- 紅包雨：發紅包、卡券以及視頻補貼紅包，其中紅包和卡券最高分別 180w QPS;
- 煙火大會：發紅包、卡券以及頭像掛件。
3. 錢包資產中臺設計與實現
在 2022 年春節活動中，UG 主要負責活動的玩法實現，包含集卡、紅包雨以及煙火大會等具體的活動相關業務邏輯和穩定性保障。而錢包方向定位是大流量場景下實現獎勵入賬、獎勵展示、獎勵使用與資金安全保障的相關任務。其中資產中臺負責獎勵發放與獎勵展示部分。
3.1 春節資產資產中臺總體架構圖如下：
錢包資產中臺核心系統劃分如下：
資產訂單層：收斂八端獎勵入賬鏈路，提供統一的接口協議對接上游活動業務方如 UG、激勵中臺、視頻紅包等的獎勵發放功能，同時對上游屏蔽對接獎勵業務下游的邏輯處理，支持預算控制、補償、訂單號冪等。
活動錢包 api 層：收斂八端獎勵展示鏈路，同時支持大流量場景
3.2 資產訂單中心設計
核心發放模型：
說明：
- 活動 ID 唯一區分一個活動，本次春節分配了一個單獨的母活動 ID
- 場景 ID 和具體的一種獎勵類型一一對應，定義該場景下發獎勵的唯一配置，場景 ID 可以配置的能力有：發獎勵賬單文案;是否需要補償;限流配置;是否進行庫存控制;是否要進行對賬。提供可插拔的能力，供業務可選接入。
實現效果：
- 實現不同活動之間的配置隔離
- 每個活動的配置呈樹狀結構，實現一個活動發多種獎勵，一種獎勵發多種獎勵 ID
- 一種獎勵 ID 可以有多種分發場景，支持不同場景的個性化配置
訂單號設計：
資產訂單層支持訂單號維度的發獎冪等，訂單號設計邏輯為${actID}_${scene_id}_${rain_id}_${award_type}_${statge}，從單號設計層面保證不超發，每個場景的獎勵用戶最多只領一次。
4. 核心難點問題解決
4.1 難點一：支持八端獎勵數據互通
前文背景已經介紹過了，參與 2022 年春節活動一共有八個產品端，其中抖音系和頭條系 APP 是不同的賬號體系，所以不能通過用戶 ID 打通獎勵互通。具體解決方案是字節賬號中臺打通了八端的賬號體系給每個用戶生成唯一的 actID(手機號優先級最高，如果不同端登錄的手機號一樣，在不同端的 actID 是一致的)。錢包側基于字節賬號中臺提供的唯一 actID 基礎上，設計實現了支持八端獎勵入賬、查看與使用的通用方案，即每個用戶的獎勵數據是綁定在 actID 上的，入賬和查詢是通過 actID 維度實現的，即可實現八端獎勵互通。
示意圖如下：
4.2 難點二：高場景下的獎勵入賬實現
每年的春節活動，發現金紅包都是最關鍵的一環，今年也不例外。有幾個原因如下：
- 預估發現金紅包最大流量有 180w TPS。
- 現金紅包本身價值高，需要保證資金安全。
- 用戶對現金的敏感度很高，在保證用戶體驗與功能完整性同時也要考慮成本問題。
終上所述，發現金紅包面臨比較大的技術挑戰。
發紅包其實是一種交易行為，資金流走向是從公司成本出然后進入個人賬戶。
(1)從技術方案上是要支持訂單號維度的冪等，同一訂單號多次請求只入賬一次。訂單號生成邏輯為${actID}_${scene_id}_${rain_id}_${award_type}_${statge}，從單號設計層面保證不超發。
(2)支持高并發，有以下 2 個傳統方案：
以上兩種傳統意義上的技術方案都有明顯的缺點，那么進行思考，既能相對節約資源又能保證用戶體驗的方案是什么?
最終采用的是紅包雨 token 方案，具體方案是使用異步入賬加較少量分布式存儲和較復雜方案來實現，下面具體介紹一下。
4.2.1 紅包雨 token 方案：
本次春節活動在紅包雨/集卡開獎/煙火大會的活動下有超大流量發紅包的場景，前文介紹過發獎 QPS 最高預估有 180w QPS，按照現有的賬戶入賬設計，需要大量存儲和計算資源支撐，根據預估發放紅包數/產品最大可接受發放時間，計算得到錢包實際入賬最低要支持的 TPS 為 30w，所以實際發放中有壓單的過程。
設計目標：
在活動預估給用戶發放(180w)與實際入賬(30w)有很大 gap 的情況下，保證用戶的核心體驗。用戶在前端頁面查看與使用過當中不能感知壓單的過程，即查看與使用體驗不能受到影響，相關展示的數據包含余額，累計收入與紅包流水，使用包含提現等。
具體設計方案：
我們在大流量場景下每次給用戶發紅包會生成一個加密 token(使用非對稱加密，包含發紅包的元信息：紅包金額，actID，與發放時間等)，分別存儲在客戶端和服務端(容災互備)，每個用戶有個 token 列表。每次發紅包的時候會在 Redis 里記錄該 token 的入賬狀態，然后用戶在活動錢包頁看到的現金紅包流水、余額等數據，是合并已入賬紅包列表+token 列表-已入賬/入賬中 token 列表的結果。同時為保證用戶提現體驗不感知紅包壓單流程，在進入提現頁或者點擊提現時將未入賬的 token 列表進行強制入賬，保證用戶提現時賬戶的余額為應入賬總金額，不 block 用戶提現流程。
示意圖如下：
token 數據結構：
token 使用的是 pb 格式，經單測驗證存儲消耗實際比使用 json 少了一倍，節約請求網絡的帶寬和存儲成本;同時序列化與反序列化消耗 cpu 也有降低。
// 紅包雨token結構
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 ` // 活動ID
SceneID string `protobuf: bytes,4,opt json: SceneID,omitempty ` // 場景ID
Amount int64 `protobuf: varint,5,opt json: Amount,omitempty ` // 紅包金額
OutTradeNo string `protobuf: bytes,6,opt json: OutTradeNo,omitempty ` // 訂單號
OpenTime int64 `protobuf: varint,7,opt json: OpenTime,omitempty ` // 開獎時間
RainID int32 `protobuf: varint,8,opt,name=rainID json: rainID,omitempty ` // 紅包雨ID
Status int64 `protobuf: varint,9,opt,name=status json: status,omitempty ` //入賬狀態
}
token 狀態機流轉：
在調用賬戶真正入賬之前會置為處理中(2)狀態，調用賬戶成功為成功(8)狀態，發紅包沒有失敗的情況，后續都是可以重試成功的。
token 安全性保障：
采用非對稱加密算法來保障存儲在的客戶端盡可能不被破解，其中加密算法為秘密倉庫，限制其他人訪問。同時考慮極端情況下如果 token 加密算法被黑產破譯，可監控報警發現，可降級。
4.2.2 活動錢包頁展示紅包流水
需求背景：
活動錢包頁展示的紅包流水是現金紅包入賬流水、提現流水、c2c 紅包流水三個數據源的合并，按照創建時間倒敘排列，需要支持分頁，可降級，保證用戶體驗不感知發現金紅包壓單過程。
4.3 難點三：發獎勵鏈路依賴多的穩定性保障
發紅包流程降級示意圖如下：
根據歷史經驗，實現的功能越復雜，依賴會變多，對應的穩定性風險就越高，那么如何保證高依賴的系統穩定性呢?
解決方案：
現金紅包入賬最基礎要保障的功能是將用戶得到的紅包進行入賬，同時支持冪等與預算控制(避免超發)，紅包賬戶的冪等設計強依賴數據庫保持事務一致性。但是如果極端情況發生，中間的鏈路可能會出現問題，如果是弱依賴需要支持降級掉，不影響發放主流程。錢包方向發紅包最短路徑為依賴服務實例計算資源和 MySQL 存儲資源實現現金紅包入賬。
發紅包強弱依賴梳理圖示：
4.4 難點四：大流量發卡券預算控制
需求背景：
春節活動除夕晚上 7 點半會開始煙火大會，是大流量集中發券的一個場景，錢包側與算法策略配合進行卡券發放庫存控制，防止超發。
具體實現：
(1)錢包資產中臺維護每個卡券模板 ID 的消耗發放量。
(2)每次卡券發放前算法策略會讀取錢包 sdk 獲取該卡券模板 ID 的消耗量以及總庫存數。同時會設置一個閾值，如果卡券剩余量小于 10%后不發這個券(使用兜底券或者祝福語進行兜底)。
(3) 同時錢包資產中臺方向在發券流程累計每個券模板 ID 的消耗量(使用 Redis incr 命令原子累加消耗量)，然后與總活動庫存進行比對，如果消耗量大于總庫存數則拒絕掉，防止超發，也是一個兜底流程。
具體流程圖：
優化方向：
(1)大流量下使用 Redis 計數，單 key 會存在熱 key 問題，需要拆分 key 來解決。
(2)大流量場景下操作 Redis 會存在超時問題，返回上游處理中，上游繼續重試發券會多消耗庫存少發，本次春節活動實際活動庫存在預估庫存基礎上加了 5%的量級來緩解超時帶來的少發問題。
4.5 難點五：高 QPS 場景下的熱 key 的讀取和寫入穩定性保障
需求背景：
在除夕晚上 7 點半開始會開始煙火大會活動，展示所有紅包雨與煙火大會紅包的實時累計發放總額，最大流量預估讀取有 180wQPS，寫入 30wQPS。
這是典型的超大流量，熱點 key、更新延遲不敏感，非數據強一致性場景(數字是一直累加)，同時要做好容災降級處理，最后實際活動展示的金額與產品預計發放數值誤差小于 1%。
4.5.1 方案一
提供 sdk 接入方式，復用了主會場機器實例的資源。高 QPS 下的讀取和寫入單 key，比較容易想到的是使用 Redis 分布式緩存來進行實現，但是單 key 讀取和寫入的會打到一個實例上，壓測過單實例的瓶頸為 3w QPS。所以做的一個優化是拆分多個 key，然后用本地緩存兜底。
具體寫入流程：
設計拆分 100 個 key，每次發紅包根據請求的 actID%100 使用 incr 命令累加該數字，因為不能保證冪等性，所以超時不重試。
讀取流程：
與寫入流程類似，優先讀取本地緩存，如果本地緩存值為為 0，那么去讀取各個 Redis 的 key 值累加到一起，進行返回。
問題：
(1)拆分 100 個 key 會出現讀擴散的問題，需要申請較多 Redis 資源，存儲成本比較高。而且可能存在讀取超時問題，不能保證一次讀取所有 key 都讀取成功，故返回的結果可能會較上一次有減少。
(2)容災方案方面，如果申請備份 Redis，也需要較多的存儲資源，需要的額外存儲成本。
4.5.2 方案二
設計思路：
在方案一實現的基礎上進行優化，并且要考慮數字不斷累加、節約成本與實現容災方案。在寫場景，通過本地緩存進行合并寫請求進行原子性累加，讀場景返回本地緩存的值，減少額外的存儲資源占用。使用 Redis 實現中心化存儲，最終大家讀到的值都是一樣的。
具體設計方案：
每個 docker 實例啟動時都會執行定時任務，分為讀 Redis 任務和寫 Redis 任務。
讀取流程：
- 本地的定時任務每秒執行一次，讀取 Redis 單 key 的值，如果獲取到的值大于本地緩存那么更新本地緩存的值。
- 對外暴露的 sdk 直接返回本地緩存的值即可。
- 有個問題需要注意下，每次實例啟動第一秒內是沒有數據的，所以會阻塞讀，等有數據再返回。
寫入流程：
- 因為讀取都是讀取本地緩存(本地緩存不過期)，所以處理好并發情況下的寫即可。
- 本地緩存寫變量使用 go 的 atomic.AddInt64 支持原子性累加本地寫緩存的值。
- 每次執行更新 Redis 的定時任務，先將本地寫緩存復制到 amount 變量，然后再將本地寫緩存原子性減去 amount 的值，最后將 amount 的值 incr 到 Redis 單 key 上，實現 Redis 的單 key 的值一直累加。
- 容災方案是使用備份 Redis 集群，寫入時進行雙寫，一旦主機群掛掉，設計了一個配置開關支持讀取備份 Redis。兩個 Redis 集群的數據一致性，通過定時任務兜底實現。
本方案調用 Redis 的流量是跟實例數成正比，經調研讀取側的服務為主會場實例數 2 萬個，寫入側服務為資產中臺實例數 8 千個，所以實際 Redis 要支持的 QPS 為 2.8 萬/定時任務執行間隔(單位為 s)，經壓測驗證 Redis 單實例可以支持單 key2 萬 get，8k incr 的操作，所以設置定時任務的執行時間間隔是 1s，如果實例數更多可以考慮延長執行時間間隔。
具體寫入流程圖如下：
4.5.3 方案對比
結論：
從實現效果，資源成本和容災等方面考慮，最終選擇了方案二上線。
4.6 難點六：進行母活動與子活動的平滑切換
需求背景：
為了保證本次春節活動的最終上線效果和交付質量，實際上分了三個階段進行的。
(1)第一階段是內部人員測試階段。
(2)第二個階段是外部演練階段，圈定部分外部用戶進行春節活動功能的驗證(灰度放量)，也是發現暴露問題以及驗證對應解決機制最有效的手段，影響面可控。
(3)第三個階段是正式春節活動。
而產品的需求是這三個階段是分別獨立的階段，包含用戶獲得獎勵、展示與使用獎勵都是隔離的。
技術挑戰：
有多個上游調用錢包發獎勵，同時錢包有多個獎勵業務下游，所以大家一起改本身溝通成本較高，配置出錯的概率就比較大，而且不能同步改，會有較大的技術安全隱患。
設計思路:
作為獎勵入賬的唯一入口，錢包資產中臺收斂了整個活動配置切換的實現。設計出母活動和子活動的分層配置，上游請求參數統一傳母活動 ID 代表春節活動，錢包資產中臺根據請求時間決定采用哪個子活動配置進行發獎，以此來實現不同時間段不同活動的產品需求。降低了溝通成本，減少了配置出錯的概率，并且可以同步切換，較大地提升了研發與測試人效。
示意圖：
4.7 難點七：大流量場景下資金安全保障
錢包方向在本次春節活動期間做了三件事情來保障大流量大預算的現金紅包發放的資金安全：
- 現金紅包發放整體預算控制的攔截
- 單筆現金紅包發放金額上限的攔截
- 大流量發紅包場景的資金對賬
- 小時級別對賬：支持紅包雨/集卡/煙火紅包發放 h+1 小時級對賬，并針對部分場景設置兜底 h+2 核對。
- 準實時對賬：紅包雨已入賬的紅包數據反查錢包資產中臺和活動側做準實時對賬
多維度核對示意圖：
準實時對賬流程圖：
說明：
準實時對賬監控和報警可以及時發現是否異常入賬情況，如果報警發現會有緊急預案處理。
5. 通用模式抽象
在經歷過春節超大流量活動后的設計與實現后，有一些總結和經驗與大家一起分享一下。
5.1 容災降級層面
大流量場景，為了保證活動最終上線效果，容災是一定要做好的。參考業界通用實現方案，如降級、限流、熔斷、資源隔離，根據預估活動參與人數和效果進行使用存儲預估等。
5.1.1 限流層面
(1)限流方面應用了 api 層 nginx 入流量限流，分布式入流量限流，分布式出流量限流。這幾個限流器都是字節跳動公司層面公共的中間件，經過大流量的驗證。
(2)首先進行了實際單實例壓測，根據單實例扛住的流量與本次春節活動預估流量打到該服務的流量進行擴容，并結合下游能抗住的情況，在 tlb 入流量、入流量限流以及出流量限流分別做好了詳細完整的配置并同。
限流目標：
保證自身服務穩定性，防止外部預期外流量把本身服務打垮，防止造成雪崩效應，保證核心業務和用戶核心體驗。
簡單集群限流是實例維度的限流，每個實例限流的 QPS=總配置限流 QPS/實例數，對于多機器低 QPS 可能會有不準的情況，要經過實際壓測并且及時調整配置值。
對于分布式入流量和出流量限流，兩種使用方式如下，每種方式都支持高低 QPS，區別只是 SDK 使用方式和功能不同。一般低 QPS 精度要求高，采用 redis 計數方式，使用方提供自己的 redis 集群。高 QPS 精度要求低，退化為總 QPS/tce 實例數的單實例限流。
5.1.2 降級層面
對于高流量場景，每個核心功能都要有對應的降級方案來保證突發情況核心鏈路的穩定性。
(1)本次春節獎勵入賬與活動活動錢包頁方向做好了充分的操作預案，一共有 26 個降級開關，關鍵時刻棄車保帥，防止有單點問題影響核心鏈路。
(2)以發現金紅包鏈路舉例，錢包方向最后完全降級的方案是只依賴 docker 和 MySQL，其他依賴都是可以降級掉的，MySQL 主有問題可以緊急聯系切主，雖說最后一個都沒用上，但是前提要設計好保證活動的萬無一失。
5.1.3 資源隔離層面
(1)提升開發效率不重復造輪子。因為錢包資產中臺也日常支持抖音資產發放的需求，本次春節活動也復用了現有的接口和代碼流程支持發獎。
(2)同時針對本次春節活動，服務層面做了集群隔離，創建專用活動集群，底層存儲資源隔離，活動流量和常規流量互不影響。
5.1.4 存儲預估
(1)不但要考慮和驗證了 Redis 或者 MySQL 存儲能抗住對應的流量，同時也要按照實際的獲取參與和發放數據等預估存儲資源是否足夠。
(2)對于字節跳動公司的 Redis 組件來講，可以進行垂直擴容(每個實例增加存儲，最大 10G)，也可以進行水平擴容(單機房上限是 500 個實例)，因為 Redis 是三機房同步的，所以計算存儲時只考慮一個機房的存儲上限即可。要留足 buffer，因為水平擴容是很慢的一個過程，突發情況遇到存儲資源不足只能通過配置開關提前下掉依賴存儲，需要提前設計好。
5.1.5 壓測層面
本次春節活動，錢包獎勵入賬和活動錢包頁做了充分的全鏈路壓測驗證，下面是一些經驗總結。
在壓測前要建立好壓測整條鏈路的監控大盤，在壓測過程當中及時和方便的發現問題。
對于 MySQL 數據庫，在紅包雨等大流量正式活動開始前，進行小流量壓測預熱數據庫，峰值流量前提前建鏈，減少正式活動時的大量建鏈耗時，保證發紅包鏈路數據庫層面的穩定性。
壓測過程當中一定要傳壓測標，支持全鏈路識別壓測流量做特殊邏輯處理，與線上正常業務互不干擾。
針對壓測流量不做特殊處理，壓測流量處理流程保持和線上流量一致。
壓測中要驗證計算資源與存儲資源是否能抗住預估流量
- 梳理好壓測計劃，基于歷史經驗，設置合理初始流量，漸進提升壓測流量，實時觀察各項壓測指標。
- 存儲資源壓測數據要與線上數據隔離，對于 MySQL 和 Bytekv 這種來講是建壓測表，對于 Redis 和 Abase 這種來講是壓測 key 在線上 key 基礎加一下壓測前綴標識 。
- 壓測數據要及時清理，Redis 和 Abase 這種加短時間的過期時間，過期機制處理比較方便，如果忘記設置過期時間，可以根據寫腳本識別壓測標前綴去刪除。
壓測后也要關注存儲資源各項指標是否符合預期。
5.2 微服務思考
在日常技術設計中，大家都會遵守微服務設計原則和規范，根據系統職責和核心數據模型拆分不同模塊，提升開發迭代效率并不互相影響。但是微服務也有它的弊端，對于超大流量的場景功能也比較復雜，會經過多個鏈路，這樣是極其消耗計算資源的。本次春節活動資產中臺提供了 sdk 包代替 rpc 進行微服務鏈路聚合對外提供基礎能力，如查詢余額、判斷用戶是否獲取過獎勵，強制入賬等功能。訪問流量最高上千萬，與使用微服務架構對比節約了上萬核 CPU 的計算資源。
6. 系統的未來演進方向
- 梳理上下游需求和痛點，優化資產中臺設計實現，完善基礎能力，優化服務架構，提供一站式服務，讓接入活動方可以更專注進行活動業務邏輯的研發工作。
- 加強實時和離線數據看板能力建設，讓獎勵發放數據展示的更清晰更準確。
- 加強配置化和文檔建設，對內減少對接活動的對接成本，對外提升活動業務方接入效率。
