支付账务清结算系统设计

账务清结算系统职责概述

账务清结算系统是支付系统的资金控制管理模块，分为账务和清结算两部分功能。

一、账务

账务系统为外部客户和内部管理者提供符合公司内部财务核算的各种会计凭证、账簿与财务报表，一般分为实时入账和日终批处理两个部分来设计。

• 实时入账模块负责在线完成客户账户余额更新

• 日终批处理模块负责日终余额校验并完成会计报表统计

二、清结算

清结算是支付业务的资金计算模块，包括清算(Clearing)、结算(Settlement)和对账(Statement)三个功能，最终目的是实现与商户的货款两清。

• 清算是根据交易结果和协议规定，对交易的客户备付金、商户手续费、银行成本和其他款项进行计算，明确每个客户的应收应付金额

• 结算是根据结算周期规定，对清算产生的应收应付金额，完成资金的划拨；对账最终完成货款两清

• 对账过程中交易成员对收付的结算款项核对、确认，确保自身权益不受影响

系统建设过程中的关键点

账务清结算系统是支付的核心系统，承接支付的所有交易的资金处理。所以账务清结算系统在设计过程中除了满足基本的结算业务规则和财务会计规则，还需要根据互联网支付业务的特点，额外考虑以下几点：

• 实时交易，交易总量大，交易峰值不可控

• KA 商户模式，数据库存在热点账户问题，并且资金数据是敏感数据，要求绝对的准确，所以数据库表拆分方案复杂

• 结算模式多样，千人千面结算计费规则

系统的功能架构

在三方支付场景中，账务和清结算是交易的必要一环，入账和清结算请求，来自交易支付系统。支付交易的标准入账结算信息流如下图：

交易支付系统分别通知账务和清结算模块，完成交易入账和交易清结算处理，清结算完成结算后再次调用入账完成结算款划拨。之所以分开并行完成交易入账和清结算请求，原因有二点：

• 其一，账务的维度和交易的资金出入要一一对应，对于组合支付、合单支付场景，一笔支付不能完全对应一笔结算，需要在支付交易系统明确订单拆分规则，依商户订单模式报送清结算，依支付订单维度报送账务。

• 其二，账务和清结算分开，可以在内部做一个弱校验，这样即使其中一个系统出问题，也可以保证不产生资损损失，降低资金风险。

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

一、前置接口 对外系统提供不同的协议服务，以完成账务入账和结算逻辑。其主要处理三部分工作：流量控制、数据校验和流程决策。

• 流量控制：对接口流量控制，防止流量洪峰；对单账户控制，防止热点账户导致数据库性能下降，影响服务。

• 校验中心：完成交易的完整性校验、幂等性校验、账户状态的可用性校验等。

• 决策中心：完成交易和记账规则、结算规则的匹配，同时处理熔断机制下的业务降级决策。

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

难点处理思路

一、热点账户处理

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

账务处理是避免不了数据库行锁的。如果一次账务处理数据库事务 10ms，对热点账户处理的 tps 最大是 100，一旦超过这个阈值，频繁的锁竞争会使得数据库性能急剧下降。

热点账户分出款热点和入款热点。入款热点常用的做法是缓冲入账，将入款交易缓冲，按照一定的处理速度做账务处理，使得账务处理速度低于 tps 的阈值，保证数据库性能稳定；如果在逐笔缓冲处理仍有压力，可以使用汇总缓冲。出款热点如果采用缓冲，可能会导致不良结果，一般不采用，通常对出款热点的处置有三种方法：

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

• 数据库水平拆分，账务系统的账户记录分散到不同机器的不同表中。再对有热点的账户逻辑拆分成多个账户，使拆分的多个账户分散到不同机器的不同表中。热点账户变成多个账户，降低账户热度。

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

以上三个方案是出款热点的常用三个做法，在我们的账务清结算系统中采用的是分布式缓存的方式，包括：账户余额实时处理模块、账户余额缓存处理模块和定时补偿处理模块。下图是业务处理流程图：

• 账户余额实时处理模块：主要两个功能，其一是接受客户端出款请求，转发到账户余额缓存处理模块处理；其二是做实际的数据库余额操作，接受缓存处理模块或定时检查模块请求汇总更新数据库。

• 账户余额缓存处理模块：余额缓存处理模块是最重要的功能模块，负责用户出款请求。余额缓存处理模块主要有申请缓存余额、余额缓存出款、汇总更新余额功能。

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

二、数据库拆分

账务清结算系统数据量大，数据分布不均匀，数据使用需求复杂，为了更好的存储并使用数据，需要对数据库做拆分。账务清结算数据按用途分，大致有几种使用需求：

• 每笔交易记录借贷双方，便于日终余额核对，同时满足会计上凭证需求。因此需要满足交易的日统计需求；

• 商户结算账单查询需求，商户 T+1 日需要核对 T 日结算账单数据，需要满足商户按日实时查询需求；

• 小微商户结算周期多变、对账周期长，需要满足小微商户按月账单读取，甚至按季度账单读取。

基于热点账户和以上的主要需求，我们队数据库表拆分规则如下：

首先，按照客户属性完成拆分。对于资金渠道方的数据，需要满足按日汇总和 T-2 日对账需求，这部分数据采用按日一级拆分，为避免一日内交易过的，按订单 hash 拆分到不同表中，尽量保证单表的记录在几百万以内。

对于商户数据，由于支付商户分小微普惠型商户和 KA 商户。这两类商户的诉求不尽相同，KA 商户资金流大，交易笔数多，要求日清日结，对这部分商户数据，按商户+日期+订单号拆分，控制单笔记录几百万以内，保证单日商户数据的查询效率。对于小微商户，交易量小，查询时间跨度长，只按照商户号做一级拆分。

三、结算规则多样

针对商户计费结算规则多变的场景，我们设计了一个标准的算法指令，指令可以完成数值比较、四则运算、数据赋值等操作。还设计了一套算法组合标准，把若干个算法按照标准组装成一个算法执行策略，通过对算法策略包含的每个算法指令的执行，完成计费结算逻辑。执行的流程图如下：

系统执行算法策略先按执行顺序获取所有的指令集合；

• 取第一条指令，判断指令类型，如果指令类型为运算指令，执行数据运算把结果赋值后，获取下一条指令重复上述操作；

• 如果是判断指令，执行判断运算，如果结果为假，获取下一条指令重复上述操作，如果结果为真，获取操作结果中储存的步骤序号，跳转到对应步骤重复上述执行操作；

• 如果是结束指令，算法结束。

以上是我们在账务清结算系统设计过程中的一些想法，后续会继续在热点账户、限流等方面做进一步优化，欢迎有经验的专家与我们沟通分享经验。