作者 | 小黑哥
导读 ：百度交易中台资产零碎是基于百度收银台和交易系统下，对公司内 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 计划
前后端数据接口合作提效实际
前端的状态治理与工夫旅行：San 实际篇
百度 App 低端机优化 - 启动性能优化（概述篇）