作者 | 小黑哥
导读：百度交易中台资产系统是基于百度收银台和交易系统下，对公司内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————
参考资料：
推荐阅读：
流日志轻松应对“10亿级别IP对”复杂场景，实现超大规模混合云网络流量可视化