支付账务清结算系统设计

1 账务清结算系统职责概述

账务清结算系统是支付系统的资金控制管理模块,分为:

1.1 账务

账务系统为外部客户和内部管理者提供符合公司内部财务核算的各种会计凭证、账簿与财务报表,一般分为:

  • 实时入账模块,负责在线完成客户账户余额更新
  • 日终批处理模块,负责日终余额校验并完成会计报表统计

1.2 清结算

支付业务的资金计算模块,最终目的是实现与商户的货款两清,功能包括:

  • **清算(Clearing)**是根据交易结果和协议规定,对交易的客户备付金、商户手续费、银行成本和其他款项进行计算,明确每个客户的应收应付金额
  • **结算(Settlement)**是根据结算周期规定,对清算产生的应收应付金额,完成资金的划拨;对账最终完成货款两清
  • **对账(Statement)**过程中交易成员对收付的结算款项核对、确认,确保自身权益不受影响

2 建设重点

账务清结算系统承接支付的所有交易的资金处理。除了满足基本结算业务规则和财务会计规则,还需根据互联网支付业务特点,额外考虑:

  • 实时交易,交易总量大,交易峰值不可控
  • KA 商户模式,数据库存在热点账户问题,并且资金数据是敏感数据,要求绝对的准确,所以数据库表拆分方案复杂
  • 结算模式多样,千人千面结算计费规则

3 系统功能架构

三方支付场景中,账务和清结算是交易的必要一环,入账和清结算请求,来自交易支付系统。

3.1 支付交易的标准入账结算信息流

交易支付系统分别通知账务、清结算模块,完成交易入账、交易清结算处理,清结算完成结算后再次调用入账完成结算款划拨。

那么,为啥要分开并行完成交易入账和清结算请求呢?

  • 账务的维度和交易的资金出入要一一对应,组合支付、合单支付场景,一笔支付不能完全对应一笔结算,需在支付交易系统明确订单拆分规则,依商户订单模式报送清结算,依支付订单维度报送账务
  • 账务和清结算分开,可在内部做一个弱校验,即使其中一个系统出问题,也可保证不产生资损,降低资金风险

账务清结算系统接收到支付的指令后,根据业务流程、账务规则和结算规则,设计账务清结算系统的组成结构:

一、前置接口 对外系统提供不同的协议服务,以完成账务入账和结算逻辑。主要处理:

  • 流量控制:对接口流量控制,防止流量洪峰;对单账户控制,防止热点账户影响
  • 校验中心:完成交易的完整性校验、幂等性校验、账户状态的可用性校验等
  • 决策中心:完成交易和记账规则、结算规则的匹配,同时处理熔断机制下的业务降级决策

二、账务清结算业务处理,账务结算的核心处理模块。这部分业务是根据传统的结算业务规则、账务会计规则,通过技术手段实现自动化结算业务、记账业务和会计报表业务。

4 技术难点

4.1 热点账户

即正常交易过程的某个特定时间段内,出现频次特高的账户。若数据库异常重试或交易故障的人工恢复等处理导致的高频,一般不作热点账户。

账务处理避免不了数据库行锁。若一次账务处理数据库事务 10ms,对热点账户处理 TPS 最大 100,一旦超过阈值,频繁锁竞争会使数据库性能骤降。

热点账户分类:

4.1.1 入款热点

入款热点常用的做法是缓冲入账,将入款交易缓冲,按照一定的处理速度做账务处理,使得账务处理速度低于 tps 的阈值,保证数据库性能稳定;如果在逐笔缓冲处理仍有压力,可以使用汇总缓冲。

4.1.2 出款热点

出款热点若采用缓冲,可能导致不良结果,一般不采用,通常对出款热点的处置方案:

① 数据库驱动层改写

由数据库驱动层检测数据库行锁,在规定时间周期内,合并更新,统一返回处理结果,类似汇总入账,降低热点的更新频度

② 数据库水平拆分

账务系统的账户记录分散到不同机器的不同表。再对有热点的账户逻辑拆分成多个账户,使拆分的多个账户分散到不同机器的不同表。热点账户变成多个账户,降低账户热度

③ 应用层实现

通过分布式缓存,冻结部分商户资金放在分布式缓存中,由缓存实时扣款。最终再同步到账户余额。

本文账务清结算系统采用分布式缓存方案,包括:账户余额实时处理模块、账户余额缓存处理模块和定时补偿处理模块。

4.2 业务处理模块

4.2.0 流程图

4.2.1 账户余额实时处理

  • 接受客户端出款请求,转发到账户余额缓存处理模块处理
  • 做实际的数据库余额操作,接受缓存处理模块或定时检查模块请求汇总更新数据库

4.2.2 账户余额缓存处理

负责用户出款请求。申请缓存余额、余额缓存出款、汇总更新余额功能。

4.2.3 定时补偿处理

为防止缓存异常等问题导致用户余额失真,定时处理模块定期检查缓存申请的余额处理情况和缓存状态,在缓存过期时调用余额实时处理模块刷新用户余额。

5 数据库拆分

账务清结算数据按用途分:

  • 每笔交易记录借贷双方,便于日终余额核对,同时满足会计上凭证需求

    需满足交易的日统计需求

  • 商户结算账单查询需求,商户 T+1 日需要核对 T 日结算账单数据

    需满足商户按日实时查询需求

  • 小微商户结算周期多变、对账周期长

    需满足小微商户按月账单读取,甚至按季度账单读取

基于热点账户和主要需求,数据库表拆分规则:

image-20240126151412432

先按客户属性完成拆分:

  • 资金渠道方的数据,需满足按日汇总和 T-2 日对账需求,这部分数据采用按日一级拆分,为避免一日内交易过的,按订单 hash 拆分到不同表中,尽量保证单表的记录在几百万内
  • 商户数据,由于支付商户分小微普惠型商户和 KA 商户。这两类商户诉求不尽相同
    • KA 商户资金流大,交易笔数多,要求日清日结,按商户+日期+订单号拆分,控制单笔记录几百万内,保证单日商户数据查询效率
    • 小微商户,交易量小,查询时间跨度长,只按商户号一级拆分

6 结算规则

针对商户计费结算规则多变,设计个标准的算法指令,指令可完成数值比较、四则运算、数据赋值等操作。还设计一套算法组合标准,把若干算法按标准组装成算法执行策略,通过对算法策略包含的每个算法指令的执行,完成计费结算逻辑。

6.1 执行流程图

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都国企技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

参考:

#24秋招求职节奏总结#
2024系统设计面试指南 文章被收录于专栏

面向 2024 校招/社招全网最新最全的系统设计面试。八年开发经验,毕业四年成为技术专家兼架构师,乐于知识分享,擅长图文讲解各种软件技术! 现如今,牛客网人均某马点评,但本质都是系统设计考量点,如: 1.多级缓存设计,如何保证缓存跟数据库的一致性? 2.设计模式,各种业务流程,到底何时何地使用何种模式? 3.玩转分布式框架 ... 更多技术重难点设计,尽在本专栏!

全部评论

相关推荐

11-27 12:36
已编辑
门头沟学院 前端工程师
Apries:这个阶段来说,很厉害很厉害了,不过写的简历确实不是很行,优势删掉吧,其他的还行
点赞 评论 收藏
分享
评论
点赞
4
分享
牛客网
牛客企业服务