作者 | 小黑哥
導讀：百度交易中台資産系統是基于百度收銀台和交易系統下，對公司内C端個人現金、虛拟類資産（虛拟币等）業務進行收攏、管理，提供安全可靠且符合國家清算規範的使用者資産管理能力。交易中台資産系統基于現有交易中台部分能力，一站式解決業務方對使用者資産管理、平台分賬、對賬、财報等問題，快速支援資産類業務發展。
全文5085字，預計閱讀時間13分鐘。
一、系統介紹
百度交易中台支援百度集團内部的代收代付B2C業務，随着集團業務發展，存在C端使用者比如好看視訊使用者打賞給C端作者的場景，傳統的B2C模式已無法滿足，于是我們提出了C2C支付模式。
△圖1-1 支付模式
C2C模式即C端使用者與C端使用者進行交易的模式，其中最重要的一個組成部分，就是需要一個系統能夠承接C端使用者的相關資産資訊，且可以對其進行管理，于是我們設計了資産系統進行承接。百度交易中台資産系統是基于百度收銀台和交易系統下，對百度内C端個人現金、虛拟類資産（虛拟币等）業務進行收攏、管理（充值、消費、退款、贈送、提現、計稅等），提供安全可靠且符合國家清算規範的完整使用者資産管理能力。交易中台資産系統基于現有交易中台部分能力，一站式解決業務方對使用者資産管理、平台分賬、對賬、财報等問題，快速支援資産類業務發展。
二、主要業務場景
目前，交易中台資産系統已接入好看視訊打賞、百度知道問一問、法律、百家号百+币等20+業務線，主要支援虛拟币類、現金類、資産類三種核心場景：
△圖2-1 誇誇币（虛拟币類）
虛拟币類：主要服務于百度内虛拟币類相關業務，按照業務線币種隔離，支援單币種多元度賬戶：iOS賬戶、Android賬戶，充值戶、贈送戶；支援賬戶建立、資産增加、資産扣減等基礎賬戶能力；具備購買、退款、轉賬、消費、逆向消費、餘額查詢、流水查詢等通用業務能力；支援跨業務線币種轉換能力；支援币過期回收。
△圖2-2 現金類（好看贊賞）
現金類：主要服務于百度内容變現相關産品線，側重于現金類管理。資産系統提供了使用者從支付到消費再到結算、計稅、提現的整體流程；多賬戶，支援多元度賬戶：iOS賬戶、Android賬戶；支援勞務報酬、偶然所得等計稅方式；按月結算(次月、季度、指定日期等)、其他（按周、天結算）結算周期進行自動結算；支援資産自動結算、業務方指定結算；支援支付寶、微信、度小滿、銀行卡多種提現方式。
△圖2-3 資産類（我的返現）
資産類：主要服務于百度内容變現相關産品線，側重于資産管理。資産系統提供了使用者資産的管理能力；多賬戶，支援多元度賬戶：iOS賬戶、Android賬戶；支援業務方請求控制結算。
三、資産業務流程
現金類資産是典型的業務場景，故如下解讀我們主要采用現金類資産流程進行介紹。接入交易中台資産系統的業務方，為使用者提供服務，使用者在服務内進行相關操作，例如充值、打賞、消費等，業務方接到使用者請求後調用交易中台交易系統完成支付、退款等操作，也可直接調用資産系統完成充值、打賞等操作，資産系統根據業務方的配置完成相關處理。業務方可配置定時提現或者由使用者主動發起提現，支援支付寶、微信、度小滿、銀行卡等多種提現方式。
△圖3-1 資産業務流程圖
四、系統詳細拆解
資産系統承接使用者核心資産資訊，在系統搭建時面臨着諸多挑戰，主要有資料一緻性、記賬準确、熱點賬戶高吞吐。針對資料一緻性挑戰，我們采用了一緻性保障方案進行解決；對于記賬準确，我們采用了複式記賬進行解決；對于熱點賬戶，我們設計了熱點賬戶方案加以解決。下面分别介紹方案細節。
4.1 資産一緻性保障
保障使用者資産資料一緻性，是個基礎必要能力，也是一個難點。我們從資産變更的環節入手，從如下兩個方面確定資産一緻性：
①支付一緻性：由于曆史包袱問題，交易系統支付接口四參數驗簽，資料存在被篡改風險。如果增減參數，且該參數參與驗簽，則整個交易鍊路都需要修改，成本高、風險大。針對此問題，我們對支付接口更新，采用全參數驗簽，支付邏輯複用進行解決。
②變更一緻性：系統内、系統間資料需要保證一緻性，我們采用最終一緻性、資料對賬來解決。
對于使用者類型，我們區分為熱點賬戶和非熱點賬戶。熱點賬戶為頻繁進行餘額操作的賬戶，比如營運賬戶。對于非熱點賬戶操作時，我們先對其加分布式鎖，加鎖成功後再進行後續資料變更，以確定資料變更準确。對于熱點賬戶，我們将其餘額資料放入分布式緩存中，資料操作時，需確定操作記錄寫入成功後再進行操作緩存資料，啟動定時任務批次同步緩存資料更新至db，具體可以參見下文第3章節熱點賬戶。
△圖4-1 轉賬提現一緻性
針對最終一緻性，我們采用基于可靠消息隊列模式，使用者發起資金提現時記錄臨時狀态，發送消息通知下遊系統進行提現，下遊提現系統按使用者配置的提現方式進行提現，完成後下遊提現系統ack資産系統，資産系統變更為完結狀态。如果中間環節失敗，利用接口幂等進行内部重試。
△圖4-2 最終一緻性
為了防止重試未解決或者其他因素導緻的資料不一緻問題，我們搭建一緻性服務，采用資料對賬進行解決。一緻性服務基于開源中間件canal，采集上下遊系統db binlog後釋出消息隊列，對賬系統進行消費消息、對賬、寫入db，如果發現問題，進行告警或者利用修複接口進行資料修複。一緻性服務在系統間準實時對賬，異步采集無侵入。一緻性服務對賬記錄報錯7日内的資料，定時清理超期資料，以保證資料量不會過大，不影響資料庫性能。
△圖4-3 資料對賬
4.2 複式記賬
為了確定記賬準确，我們引入了财務複式記賬，即扣減賬戶A金額，增加B賬戶金額，操作整體原子性，接口幂等，賬戶變更可追溯，確定使用者賬戶操作借貸平衡。
- 使用者資産的使用包括了資金的出賬方，資金入賬方；
- 原則：有扣必有增 （充值和提現除外） 每個币種下 sum（扣款） = sum(入賬)；
- 每筆轉賬原子操作：賬戶餘額計數器變動+新增一條賬戶變動明細（明細中包括 浮動數量 和 操作後餘額）；
- 設立業務平台公共資金池。
- 記錄使用者資産流傳，check使用者資産的準确性
為了確定使用者資産變更時賬戶資訊準确、可對齊，我們設計了多種賬戶類型，資産賬戶類型主要包括打賞現金賬戶、被打賞通用賬戶、被打賞提現欠款賬戶、被打賞提現賬戶四類賬戶類型。每個變更環節采用如下記賬方式：
接下來我們看下各個賬戶是如何進行進出賬計算的。
打賞現金賬戶：使用者打賞充值時，進行進賬，使用者打賞時進行出賬。
被打賞通用賬戶：使用者打賞時，進行進賬，使用者退款時進行出賬；該賬戶承接賬期内結算金額，即該賬戶賬期内正向流水全部總額減去賬期内負向（退款）流水總額；賬期結算時，進行出賬扣款。
被打賞提現賬戶：賬期結算時，該賬戶進行進賬充值，定期提現後，進行出賬扣款。
被打賞提現欠款賬戶：上一賬期的流水退款，導緻下一賬期被打賞通用賬戶不夠扣款時的記賬，會在後續賬期結算時進行補計。
結合如下示例，我們看下賬期結算：
①如4月份，2條入賬和1條出賬，通用賬戶操作記錄3條明細，4月底時通用賬戶餘額為1500，可提現賬戶餘額和提現欠款賬戶挂賬都為0；5月份又有2筆入賬，計入通用賬戶餘額；
②05.20賬期結算4月份整月金額1500，通用賬戶餘額出賬1500，可提現賬戶入賬1500，05.21發起提現，可提現賬戶出賬1500；
③6月份1條出賬和1條入賬，06.20賬期結算5月份整月金額2000，但此時通用賬戶餘額隻有1200，故隻能出賬1200，提現欠款賬戶入賬800，可提現賬戶入賬1200，06.21發起提現，可提現賬戶出賬1200；
④7月份入賬4條，07.20賬期結算6月份整月金額1200，提現欠款賬戶800，此時通用賬戶餘額有4000，故滿足提現出賬1200+800，通用賬戶餘額出賬1200，提現欠款賬戶出賬800，可提現賬戶入賬2000，07.21發起提現，可提現賬戶出賬2000。
4.3 熱點賬戶
上文第1章節提到的熱點賬戶，即某個賬戶會并發的進行賬戶餘額變動；該賬戶餘額會被多個并發轉賬請求作為競态資源。主要是偏B端類型，例如商戶、熱門主播、業務線的補齊賬戶，同時賬戶數量少、單個賬戶記賬操作并發高、資料量大。在對熱點賬戶操作時，實時記賬請求僅插入記賬明細、不更新賬戶餘額，并把賬戶明細标記為未彙總；異步彙總程式，根據标記的“未彙總”賬戶明細，異步計算出明細的操作後餘額和賬戶餘額，異步彙總到賬戶餘額。對于熱點賬戶餘額，我們拆分成賬面餘額、實際餘額、緩存餘額：
- 賬面餘額 ：餘額表餘額
- 實際餘額 ：賬面餘額+未彙總明細餘額
- 緩存餘額 ：實際餘額的即時狀态
△圖4-4 熱點賬戶
資産資料存儲，我們基于uid做的分庫分表，具體參見第五章，但熱點賬戶會在資料傾斜問題：存在大量操作記錄，導緻查詢、變更時效率越來越低。對此，我們提出了資料歸檔的方案，即啟動離線歸檔服務，将熱點賬戶的賬戶明細資料自動歸檔轉移到歸檔庫中；建立資料庫，曆史歸檔資料單獨存放。根據賬戶明細的建立時間，按月歸檔。
4.4 符合國家一清金融監管
傳統的B2C支付，就是B端商家提供服務，C端使用者購買的模式；這種模式下，B端商家将資質、銀行卡進件到有清算牌照的銀行機構進行稽核，銀行機構可根據資質資訊核查其真實性，故可對其信任。但該模式無法适用打賞、虛拟支付這種C端使用者與C端使用者間的直接支付方式類型業務需求，主要原因是被打賞、被接收一方同為C端使用者，銀行機構無法對其資訊進行真實性核查，存在風險。經由多次與合作機構銀行（具備清算牌照）讨論，最終提出個人登記簿方案：增加個人資訊進件，在銀行開辟個人登記簿模式，稽核個人資訊通過後開通個人登記簿打款，由銀行管理使用者資訊，即可滿足資金一清監管要求。
五、存儲設計方案
使用者資産流水是交易訂單量的2-5倍，受限于MySQL資料庫單機處理能力，故将資料進行拆分，不同的資料放置在不同的機器，便于機器擴容。資料拆分分為兩步，第一步進行分庫，即将不同表放不同庫不同機器上。經過第一步分庫後，容量得到了一定的提升。但是分庫并不能解決單表容量超過單機限制的問題，随着業務的發展，資産系統中的賬戶流水表、指令表、賬戶表逐漸遇到了這個問題。
針對賬戶流水表、指令表、賬戶表三張表超過單庫容量的問題，需要進行分表操作，即将表資料進行拆分。指令表按照業務方訂單号生産shardingKey，賬戶流水表按照使用者ID生成shardingKey，賬戶表按照使用者ID分表生成shardingKey，均為16分片、1024個表。單表資料拆分後，解決了寫入的問題。但由于部分特殊業務存在熱點賬戶，就會導緻一些核心平台賬戶（如百+币平台賬戶）落入的表非常大，一般賬戶的表非常小，造成比較嚴重的資料傾斜問題。針對該問題，資産系統采用了歸檔方式來進行資料整理，将3個月之前的資料認為是冷資料，通過定時任務的方式從分布式關系資料庫中遷移到曆史表中。
解決了寫資料的問題，但是如果查詢資料不在同一個分片，會帶來查詢效率的問題（多表聚合查詢），同時賬戶流水表、指令表、賬戶表分别按不同緯度産生shardingKey，聚合查詢将無從下手。在資産系統中，我們引入了ES來解決分表後複雜聚合查詢問題。我們采用canel讀取MySQL的binlog方式，将db資料準實時的同步到ES中。然後通過ES來支援對外的多緯度、準實時查詢需求。
六、結語
基于目前交易中台所接觸和前瞻性預料的業務和場景，我們設計了如上資産系統，助力上遊業務快速發展。我們的目标是支援全集團所有支付類場景，解決業務方支付、清分、結算、打款等涉及與錢相關的後顧之憂，助力業務、公司健康、快速發展。針對資産系統，存在由于特殊情況有所取舍、折中導緻的問題，也存在着因為業務快速發展、變化帶來的諸多挑戰！我們會逐漸打磨、疊代、完善、豐富資産系統的功能，助力集團業務更快、更穩的發展壯大！
————END————
參考資料：
【1】百度交易中台之訂單系統架構淺析
【2】百度交易中台之商品推廣流程建構以及實作
【3】百度交易中台之錢包系統架構淺析
【4】百度交易中台之賬房系統架構淺析
推薦閱讀：
流日志輕松應對“10億級别IP對”複雜場景，實作超大規模混合雲網絡流量可視化
百度App Android啟動性能優化-工具篇
數字人技術在直播場景下的應用
百度工程師教你玩轉設計模式（工廠模式）
超大模型工程化實踐打磨，百度智能雲釋出雲原生 AI 2.0 方案