关于交易类业务的一些注意点

  交易系统往往要和多个系统进行对接，目前对接过程很难做到事务的控制操作（我成功了，我回调了你，你执行失败了）。所以要做到失败的补偿：重试、失败通知、失败记录、订单号记录、完整的日志链跟踪。

  其次，是与银行对接的问题：金额到账延迟，失败重试超时，重复请求查询结果超次数，同一业务下多个接口调用无法回滚。像金额到账延迟还不算太大的问题，但像失败重试超时这些，就很容易导致出现大的问题。

  失败重试超时，我方调用了接口，但接口很长时间没有反馈，我方调用超时，但实际调用成功，那么在我方返回给客户的提示就会是消费失败或者充值失败，但银行方实际上调用成功，极其容易导致客诉（失败了，但我钱扣了是怎么回事）

  解决方案：目前只能调整超时时间到1分钟，并进行超时重试，需要银行方做好幂等操作。

  重复请求查询结果超次数，一般存在于异步接口，异步接口调用后需要我们自己去查询结果，那么我们不可能无限次数地去轮询结果，所以所有的异步接口都需要银行方提供回调。

  再有一个较为麻烦的问题就是，同一业务下多个接口调用无法回滚。我在一个业务中，可能需要 充值->冻结 或者 充值->划扣，这两者是同一个事务，但如果充值成功，冻结失败，就没办法将充值操作回滚，如果一直冻结失败，那这笔钱很可能被用户消费，就极易造成我方的损失。

解决方案：进行锁操作，对充值进来的这部分金额进行加锁，未完成完整业务前不允许客户进行使用。

实现方式：所有对金额进行扣减的操作必须先查询是否有充足的金额，那么我们就可以在金额查询接口上做AOP拦截，对查询出来实际金额减去我们需要锁住的金额，确保这部分金额不会被用户进行消费。

 

  再者，就是内部处理需要注意的点，首先，必须做好幂等操作，另外，每个对账户的操作都需要加锁，确保不发生换绑卡情况下进行支付充值等同步操作异常。