百度交易中台之资产系统架构浅析

图片

作者 | 小黑哥

导读:百度交易中台资产系统是基于百度收银台和交易系统下,对公司内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 低端机优化-启动性能优化(概述篇)

你可能感兴趣的:(数据库架构资产管理)