支付系统-帐户系统总结
1.1 支付通交易层模块职责:
& 接受对业务系统的订单支付.充值请求
& 账户之间转账
& 接受业务系统的提现请求
& 接受业务系统的退款请求(对上面几种业务)
1.2支付网关职责:
负责和渠道(支付宝,微信,银联)交互,记录流水号,对账
1.3账户系统职责:
& 记录账户信息
& 保障账户变动原子性和事务性.
& 记录账户变动流水
二 主要流程图
1. 充值
2. 转账
2. 提现
三 实体设计
2.1账户系统 实体设计:
帐户表 账户信息.
Account_statement: 1.记录账户变动流水记录. 2.保存法幂等控制
2.2收银台系统实体设计:
交易表: 记录外部输入的外部流水号和内部流水号相关信息
四 亮点功能
1. 转账的额度控制通过变量传递进来.
转账停留在中间环节的,重试逻辑. 单边帐.
传统信用卡,每个用户的额度不同,都是通过往卡里加钱来提升额度. ( 1. 额度增和账户增保持事务一致. 2.额度减和账户减保持事务一致,可能减款失败,如果这个用户本身已经使用了很多.)
2. 帐户的变动和流水保存处于同一个事务中.
切记 spring 的事务注解 , 异常必须设置为 throwable
3. 提现:
* 先扣帐户款再提现.
* 银行有恶心的退票记录
4. 双边帐
加减账号分别开.
4.1 操作分为加锁和不加锁.
4.1.1 外部企业账户: 加款加锁,减款不加锁.
4.1.2 内部企业账户: 加减款都不加锁. 前面增加一个减款判断. 手动提现.
4.1.3 需要时时查看余额的普通用户需要加锁.
通过分布式扩容来实现扩展性.
5. 帐户的高并发变更设计:
高并发帐户不时时扣款.
6. 非分布式事务下的时效关单问题.
底线: 任何场景都不能在不知道结果的情况下任意关单 (终态: 关闭或者成功),否则对支付来说,可能导致用户资损,或者冲退的用户体验不好. 对提现来说可能导致平台资损,提现是绝对不能提前关闭的,不能对code进行响应,而是应该对"状态"响应,code千变万化,状态收敛,低风险
优化: 尽快关单.
timeOut场景: 给用户报错,让用户重试. (错误的小技巧优化思路, 先关闭下游,关闭成功,再关闭自己. 支付可能导致退款. 提现可能导致资金损失,原因没有跨系统关单接口 ,下游还得处理好空"类似tcc分布式事务场景的悬挂问题"或者"互斥关单问题",让系统复杂,不是好的方案.)
有code:
方案1: 是否有订单号,状态是否是Init, 是则等待处理完的消息,没有那么说明没有受理成功. 直接关单,账户等业务校验异常,给用户提示, 用户重试也没有用. (需要下游遵守 即使处理异常也返回流水号和状态的逻辑,同步接口. 异步接口,处理流程异步执行. 不影响.) 如果不能重试 先关下游,再关自己 (风险点,如果下游系统有bug,已收单异常但没有返回错误码,可能导致资损, 同样需要关注"互斥关单"(类似tcc分布式事务里的"悬挂问题",实现"空pre")的问题, 提现场景的"反退票"问题)
方案2: 方案1里需要强依赖下游和良好的异常case处理. 方案2的优化是不依赖同步返回,对特定的code,而是通过自己的接口查询状态不存在(可能存在事务未提交的导致"空读")或者closed后,关下游,关自己,对用户异常提示. 其他错误都是等待同步消息 或者 1天后对账状态来确定状态.(避免事务还未提交,"空读问题")
方案3: 区分场景. 3.1 线下支付流程, 每次都生成新的流水号. 用户想重试就重试,大不了多付款,退款,重要的是能够支付成功. 3.2 线上支付,用同一个流水号. 3.3 提现: 用同一个流水号,告知用户,特殊场景,提现结果需要30分钟后. 否则提早关单返回余额会出问题.
