账务是怎样运行的

对于业务主流程可以看我的这篇文章。

本次尽量在把所有的操作分成多个阶段，每个阶段都会对已知信息做出总结。（个人绘制，配图）

基础信息说明

在开启业务之前，需要同步的几个重要信息。下面列举的信息为目的，本文中列举的所有业务场景，只是为了达到下面几个目的所使用的手段。类似于本地强事务中：AID和C的关系。

账户信息

一个客户对应一个账户，一个账户对应一笔借据，每次账务操作都需对账户上锁

锁定账户：哪条流水（连接/线程）进行的加锁（开启事务/获取资源）操作，有且只有这条流水去进行解锁，而且必须保证解锁的逻辑能够执行。

借据信息

借据维度的详细信息

借据的详细信息表：从账务角度出发，主要包含应计（已计提）应收（未还）、已还（累计已还）三种金额。以及当前借据所处的状态等（4级分类、5级分类、表内外标识等）

利率表

理论上相同产品的利率相同，但在金融领域，利率是由风控来抉择的，使用相同产品的不同人，可能出现不同的利率。

每笔借据对应的利率

贷款期供表

还款计划，核心账务运行的基础组件，所有贷款都是由不同各种各样的还款计划来构成一个完整的贷款。

期供信息和借据信息类似，换一种说法，借据信息就是由期供信息组成的。

上面提到的所有表，都是终态表，我们的目的是为了操作上面的表。但如何科学的操作终态表，就需要有流水表来记录。下面列举重要的流水表。

交易主流水

所有都会记录的主要流水，用来同步本次交易的状态

贷款交易流水

对客的交易流水，可以变相的理解为超全的paylog，包含放还款等（没有利息计提）每条记录一般都是要向客户展示的。

一笔借据绝大多数交易都会在这里展示，对于账务相关字段，大致可分为下面几种

1. 应收应计金额：本次交易后的金额
2. 应收应计发生额：本次交易需补计提的金额
3. 欠息金额：本次交易后去，欠息余额
4. 欠息发生额：本次还款实际发生的金额

• 为什么会有一个总金额？

因为支付只会用对应的金额去请求对应账户，并不关心这些钱中包含哪些内容。（由哪些金额组成）核心作为事务控制的基准，需有统一管控。

支付交易流水

登记与支付操作相关的流水，支付系统不care资金有哪些内容组成，支付只care本次交易的状态，总额等。

支付账号中存在大量补充校验信息，本文只介绍账务，固不赘述

利息计提流水

按日计提的流水单独记录，此部分流水一般不向用户展示

此流水不存在交易状态，因为一旦登记就是成功。（只有成功才会登记流水）

期供交易流水表

与期供表相同，增加了本次交易的流水号，记录每次流水交易后，期供的变化情况。

可以用此表来实现回滚。（如需）

这里不再赘述（只是在期供表上增加了流水号）

放款

放款只资金从银行到客户的提现过程。

客户角度只能看到一笔借据生成了，一笔钱到账了。

但在银行（核心）角度生意才刚刚开始，本次只列举账务，如开户行，支付用的账号等不再列举范围内。

只列举核心维系一笔账务运行的关键信息

额度等暂不放入其中，只会偶尔提到，但不深入。

放款前的准备

如果想要开始一笔贷款，必须提前准备的信息

产品信息

每笔借据都必须对应产品，不同产品可能会有各自不同的规则。

产品的目的是尽量让贷款分类，在有限的种类下给客户不同的选择

放款基础信息

在放款前置操作时准备好的字段，放款前置大部分为渠道、风险等

• 折扣率

折扣率不一定会直接提供，大部分场景下需要计算得出

固定利率：有些折扣会直接让利率固定，此场景不需要再考虑折扣率（利率已是折扣后的）

其他情况：需通过折扣率/正常利率，算出折扣率（后面为了得出优惠情况）

放款试算

所谓放款试算，只预生成借据和期供信息，相当于预放款，给客户一个完整的展示。后续实际贷款流程也会重新调用放款试算。试算更适合单独的展示账务是如何生成的。

放款全程没有事务，不涉及加锁，不涉及入库。

• 为什么不入库或加锁？

放款试算只提现如何生成借据和期供，不一定只有在预放款时调用，可能在延展期，提前部分还款等场景下都会调用。且调用频率较高，如果每次试算都入库，会生成大量无效的数据。

据了解，有些支持预放款的机构（如数禾：借呗），会把放款试算的结果保存在数据库中，来增加放款的响应速度。但放款场景下，试算是非常耗时的一环吗？？

前期准备杂项介绍

• 试算时入参

入参大部分为放款前准备阶段的已知数据，下面列举一些账务较为重要的字段

• 试算时出参

目标字段

后面会详细列出上表中每个字段的生成逻辑

根据不同的还款方式使用不同的放款试算器

等额本金试算器

最简单的贷款生成逻辑，只根据剩余本金、计息天数、日利率来计算

1. 预生成还款计算，并把本金分配到每期上

为什么要拆分本金？如果自定义还本周期，会出现多个不存在应还本金的还款计划，所以本金不一定是会拆分到每一起上的。

总期数：会生成多少期还款计划在产品配置时就已经定义。

哪些期数会被分配本金：还本周期/还息周期，后续每次增加 还本周期/还息周期

1

for(int i=还本周期/还息周期;i<总期数;i+=还本周期/还息周期)

如还本周期为2，还息周期为1，生成的还款计划就是1（只还息）2（还本还息）3（只还息）4（还本还息）…

2. 利息计算

计算每期的利息，对于首期有特殊计算逻辑

还款计划生成完成！

3. 借据字段补全

等额本金为最简单的贷款生成方式，后续其他还款方式的生成思想与等额本金相同

等额本息试算器

等额本金要提前拆分本金，等额本息由于每期还款总金额相同，所以需预拆分每期还款总额

• 如何计算每期还款总额

等额本息计算顺序有所改变：1、算出每期还款总额，2、算出当期应还利息，3、根据当期还款总额-当期应还利息=当期应还本金。

放款try

放款主要涉及三个服务联通，额度占用，借据期供生成，调用支付。（三个全部成功后才能提交）

主要介绍事务控制，单个小事务和整体分布式事务是如何结合的。

所有分布式事务，都需要考虑三个问题：幂等性，空回滚，悬挂问题，下文中会解释每个场景下问题是如何处理的。

放款账务部分有两个独立本地事务组成

流水登记（事务1）

登记三大流水

交易主流水、贷款交易流水、支付交易流水。

• 为什么使用独立事务登记流水？

事务回滚触发条件存在两种情况：

1. 流水重复入库失败：当前流水已经入库被处理，不再重复处理。（幂等性）

2. 代码出现异常，导致事务回滚：独立事务只做流水入库处理，如果和试算开户等计算逻辑放到同一个事务中，如果代码出现异常，登记的流水也会丢失。

   虽然下次相同的流水应该也会执行相同的回滚逻辑，但给系统增加了负担，所以让代码异常和流水登记分开。

开户、放款试算信息落库（事务2）

开户时生成账户信息，默认生成的账户信息为上锁状态，上锁流水为当前放款请求流水。（防止没有放款成功，此借据被其他线程消费）

给当前客户创建客户信息，走放款试算逻辑生成借据、期供。

• 落库借据

1. 落库账户信息
2. 借据信息
3. 利率信息
4. 期供信息

上述表除账户信息中存在锁状态，其他表无状态

当前阶段并没有特殊逻辑，如果本阶段出现异常回滚，说明流水中存在错误参数，无法放款。之前登记的流水也要提交，遇到相同流水无需重复试算。

放款confirm

资源占用成功，支付返回成功后，就会提交占用的资源。

由于借据相关信息已在占用阶段生成，所谓提交阶段只需提交流水信息。（把流水状态改成成功）

更新三大流水表状态为成功：交易主流水、贷款交易流水、支付交易流水。

最后阶段解锁账户

放款取消Cancel

支付返回失败，放款冲正。

取消阶段和提交阶段相同，为了保证事务/锁/资源一定可以释放，所有提交取消都是轻量级原子操作。不附加额外逻辑。

1. 更新三大流水表为失败：交易主流水、贷款交易流水、支付交易流水。

2. 最后更新账户状态为放款冲正。（失败）

try阶段落库的借据信息、期供信息等不做处理。

放款总结答疑

• 为什么只修改流水，不修改借据信息，或者是为什么不在借据信息上也增加类似账户的状态字段？

只修改流水，是为了保证提交和取消操作一定可以被执行。

只有账户信息上存在状态，其他所有非流水表都不在事务执行状态字段，是为了保证状态修改的原子性，避免死锁。

如果借据信息上存在类似账户的事务执行状态字段：加锁操作就不在是原子性的：

两个线程同时上锁：A线程线对账户加锁，后执行对借据加锁。B线程对借据加锁，后执行账户加锁。产生死锁

• 幂等性

try阶段两个独立事务，事务一登记流水，流水一旦登记，就不能再重复登记。

confirm：只按流水更新流水状态为成功，重复成功where条件中不存在当前流水号且状态为处理中的流水。

cancel：同提交操作，只更新流水。

• 空回滚

在try阶段之前，就执行了cancel逻辑。

cancel只会更新流水，由于try阶段还未执行，三大流水表中不存在流水信息，cancel逻辑只会空跑。

• 悬挂问题

额度占用成功，但借据生成执行超时，导致事务管理器已经发起了取消请求后，借据生成执行又成功了。

现有逻辑中没有考虑悬挂问题，对于这种超时后又提示占用成功的流水，会由后面的流水同步任务来让此流水走向终态。