从储值卡（会员卡）充值业务看分布式事务的设计

公司有一项储值卡充值业务：客户在微信公众号开通储值卡服务，通过微信支付往卡里面充值，充值成功后客户可收到消息通知，并进行消费。

看起来是一项很简单的业务，最初我们储值卡团队的实现也确实很简单。我们看看最初的实现：

相信聪明的你一眼就能看出问题：

1. 压根没有考虑分布式事务一致性，比如第 12 步根本没有考虑卡系统充值失败的情况该如何处理，而是默认其一定能成功；
2. 大部分的处理都是放在前端业务系统（除了这里的公众号系统，还有 POS 机系统，而 POS 机是通过调公众号系统接口来实现的）；
3. 第 4 步直接下单，第 5 步直接调微信支付，压根没有跟卡系统有任何通信：这里默认用户的充值行为一定是合法的；
4. 在微信的支付回调中（第 10 步往后），是先处理一系列业务逻辑，最后才调充值接口，这里也是默认卡充值一定能成功；

看到这里你可能会大呼开发人员是不是没长脑子？

实际情况是，这个版本的开发是几年前的事情了，那时候公司还是创业早期，第一目标是尽快上线能用，而且客户量没有那么大，虽然中间也出现过一些数据不一致的情况，也都通过人工处理了事了。

随着公司业务的发展，用户量越来越大，而且还要和第三方合作（储值卡作为一种支付方式提供给第三方使用），问题出现得也越来越频繁，不得不