万级TPS亿级流水-中台账户系统架构设计

• 背景
• 业务模型
• 应用层设计
• 数据层设计
• 日切对账

背景

我们需要给所有前台业务提供统一的账户系统，用来支撑所有前台产品线的用户资产管理，统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力，在万级TPS下保证绝对的数据准确性和数据溯源能力。

注：资金类系统只有合格和不合格，哪怕数据出现只有0.01分的差错也是不合格的，局部数据不准也就意味着全局数据都不可信。

本文只分享系统的核心模型部分的设计，其他常规类的（如压测验收、系统保护策略-限流、降级、熔断等）设计就不做多介绍，如果对其他方面有兴趣欢迎进一步交流。

业务模型

基本账户管理： 根据交易的不同主体，可以分为个人账户、机构账户。
账户余额在使用上没有任何限制，很纯粹的账户存储、转账管理，可以满足90%业务场景。

子账户功能： 一个用户可以开通多个子账户，根据余额属性不同可以分为基本账户、过期账户，根据币种不同可以分为人民币账户、虚拟币账户，根据业务形态不同可以自定义。
（不同账户的特定功能是通过账户上的账户属性来区分实现。）

过期账户管理： 该账户中的余额是会随着进账流水到期自动过期。
如：在某平台充值1000元送300元，其中300元是有过期时间的，但是1000元是没有时间限制的。这里的1000元存在你的基本账户中，300元存在你的过期账户中。

注：过期账户的每一笔入账流水都会有一个到期时间。系统根据交易流水的到期时间，自动核销用户过期账户中的余额，记为平台的确认收入。

账户组合使用：支持多账户组合使用，根据配置的优先扣减顺序进行扣减余额。比如：在 基本账户 和 过期账户 （充值账户）中扣钱一般的顺序是优先扣减过期账户的余额。

应用层设计

根据上述业务模型，账户系统是一个典型的 数据密集型系统 ，业务层的逻辑不复杂。整个系统的设计关键点在于如何平衡大并发TPS和数据一致性。

热点账户：前台直播类业务存在热点账户问题，每到各种活动赛事的时候会存在 90%DAU 给少数几个头部主播打赏的场景。
DB就会有热点行问题，由于 行锁 关系并发一大肯定大量超时、RT突增 、 DB活跃线程 增加等一系列问题，最终DB会被拖挂。

账户类系统有一个特点，原账户的扣减可以实时处理，目标账户可以异步处理，我们可以将转账动作拆解为两个阶段进行异步化。（可以参考银行转账业务。）

比如：A给B转账100元，原账户A的100元余额扣减可以同步处理，B账户的100增加可以异步处理。这样哪怕10w人给主播打赏，这10w人的账户都是分散的，而主播的余额增加则是异步处理的。

账户转账扣减A账户余额，记录A账户出账流水，记录B账户入账流水，这三个动作可以在一个DBTransaction中处理，可以保证源账户进出帐一致性。目标账户B的入账可以异步处理，为了保证万无一失且满足一定的实时性，需要两步结合，程序里通过MQ走异步入账，同时增加DB的兜底JOB定时扫描 入账流水记录 为未到账的流水进行入账。