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