这是一个银行资金监管系统生产中的真实案例，我方资金监管系统A在完成资金支付功能时，下游涉及两个系统。需要先调用系统B的解冻接口完成资金解冻，然后再调用系统C的转账接口完成资金支付。各系统间数据一致性保障，采用类似SAGA事务的思路，如果失败或异常，我方统一负责补偿或冲正处理。

系统B提供：资金解冻接口、资金冻结接口、执行结果查询接口，通过上送唯一流水号保证幂等和查询结果条件。

系统C提供：资金转账接口、转账结果查询接口，通过上送唯一流水号保证幂等和查询结果条件。

数据库表

1）支付流水表(支付流水号，解冻流水号，冻结流水号，支付状态（待处理、处理中、成功、失败、不确定），解冻状态（待处理、处理中、成功、失败、不确定），冻结状态（待处理、处理中、成功、失败、不确定），金额，付款账户，收款账户，交易日期，各种时间，版本号等)

2）冻结解冻记录表(流水号，支付流水号，类型，状态，账号，金额，时间，结果)

3）支付执行防重表(支付流水号[唯一约束])

账户主要结构：

字段：总余额、业务冻结额、可用余额，

总余额=业务冻结额+可用余额。

账户纳管后,来账资金都会被冻结到业务冻结额中，属于被监管资金。

概要业务逻辑：

1）我方系统A做支付前置校验

2) 调用资金解冻接口，解冻付款账户资金(支付金额)。(资金从业务冻结额释放到可用余额中)

3）调用资金转账接口，发起转账。（从账号可用余额中转账）

4）支付结果处理：接口返回成功/失败/其他，则更新支付状态=成功/失败/不确定

5）如果最终支付失败(终态)，调用资金冻结接口重新冻结资金。（资金从可用余额冻结到业务冻结额中）

支付简化伪代码：

1)幂等控制方法 分布式锁(可选) 检查支付状态=待处理 插入支付执行防重表(保障一笔支付申请至多执行一次付款) 版本号做为条件，CAS更新支付流水表支付状态=处理中，执行时间=? //CAS为比较交换操作，保证并发原子性，执行sql后判断影响行数不等于1则抛异常 //所有更新操作版本号默认+1 2）业务检查方法 try{ 业务检查 }catch(e){ 更新支付流水表支付状态=失败，失败原因=? throw e; } 3）付款账户资金解冻方法 try{ 版本号CAS更新支付流水表解冻状态=处理中，解冻流水号=? 记录冻结解冻记录表 调用资金解冻接口解冻资金(待支付金额)。 如果返回成功，更新支付流水表解冻状态为成功。 如果返回失败，更新支付状态设置为失败，解冻状态为失败，return。 如果返回其他(可能是处理中/不确定/超时等)，抛异常。 }catch(e){ 支付状态更新为失败，解冻状态更新为不确定。 【异步补偿定时任务，通过执行结果查询接口查询解冻结果】 throw e; } 4）账户转账方法 try{ 调用转账接口。 如果返回成功，更新支付状态为成功。 如果返回失败，更新支付状态设置为失败，执行冻结冲正方法。 如果返回其他，抛异常。 }catch(e){ 更新支付流水表支付状态=不确定 【异步补偿定时任务，通过转账结果查询接口查询结果】 throw e; }

冻结冲正简化伪代码：

try{ 查询是否解冻成功 版本号CAS更新支付流水表冻结状态=处理中，冻结流水号=? where 冻结状态 in (待处理/失败) //所有更新操作版本号默认+1 记录冻结解冻记录表 调用资金冻结接口冻结资金(支付金额)。 如果返回成功，更新支付流水表冻结状态为成功。 如果返回失败，冻结状态为失败，return。【对于冻结冲正失败的会有异步定时任务做补偿重试/短信告警】 如果返回其他(可能是处理中/不确定/超时等)，抛异常。 }catch(e){ 冻结状态更新为不确定。 【异步补偿定时任务，通过执行结果查询接口查询冻结结果，更新冻结状态】 }

补偿定时任务(异步化)

核心补偿场景1:资金解冻成功，但是付款失败/没执行付款

# 支付状态=不确定。查询支付结果更新支付状态,并更新。 # 解冻状态=不确定。查询解冻结果更新解冻状态,并更新。 # 冻结状态=不确定。查询冻结结果更新冻结状态,并更新。 # 冻结状态=处理中，执行时间>1小时。查询冻结结果更新冻结状态,并更新。 # 冻结状态=失败。重试或短信告警人工处理。 # 解冻状态=成功，支付状态=失败，冻结状态=待处理。做冻结冲正处理，重新冻结账户资金。 # 支付状态=处理中，执行时间>10分钟。按照支付状态、解冻状态不同情况，做逐一处理。调用各查询接口确定下游系统执行状态

监控定时任务(异步化)

定时检查账户金额，如果可用余额>分行设置的阈值，则报警。