只要你系统不是一个独立(不和其他进程交互)的单体应用，那就存在分布式事务 。
什么是分布式事务？
在一次调用中，针对多个数据源中的数据进行的修改，要么全部成功，要么全部失败 。也就是一致性问题。
根据CAP定理，我们知道这个一致性通常我们是不能保证的。
又通过BASE理论指导，我们可以做到最终一致性。
在我们的业务开发中，从应用层面来看，我们的应用一般都是无状态的，我们无需不存在分区隔离性。
所以C和A都可以满足。
但是强一致性有一个问题，就是吞吐不高，所以我们也不会选择强一致的解决方案。
那么最终 一致性的分布式事务的痛点在于什么？
对外部服务调用的失败。由于这个失败的起因可能是超时，所以我们无法确定失败的背后是真失败还是假失败。
处理这个调用失败有两种方式
- 保证最终全部成功
- 保证最终全部失败
保证最终全部成功
保证全部成功我们需要第三方服务有幂等保证，然后我们通过重试来保证最终成功。
那现在问题简化为如何重试？
- 上上选肯定是消息，消息中间件自带重试机制，由于发送消息也有可能失败，所以最好是使用事务消息
- 其他带重试方案
重试也不是万能的，也不能一直重试，所以也还是有漏网之鱼，所以我们需要有个兜底方案，检查各个系统的数据一致性，进行修复或告警。
经过群友讨论，实战中对重试有以下优化点
- 将分布式事务转化为本地事务，搞一张对应第三方服务的操作表，进行操作重试。
- 记录第三方操作状态，接受第三方操作成功通知，如果状态一段时间后未变化，重发消息/重新调用。(不把锅给第三方)
保证最终全部失败
一旦我调用一个第三方服务失败后，我需要让之前调用的其他第三方服务都失败(也就是回滚)，我需要通知他们。这时候我可能掉他们回滚接口，但是回滚接口也有可能失败。还是需要重试机制和幂等保证。
上上选依然是消息。
如何选择
那么我们应该选择哪种方式？从用户的角度看，用户是希望操作成功。从开发的角度看，回滚接口可能还需要额外开发。所以我们优先选择的是保证最终全部成功的方式。
能否重试
有些特殊场景下，我们严格依赖接口的返回，可能下一个接口依赖上一个接口的返回，这种场景，我们只能保证最终全部失败。
最后
在开发中，我们还是要根据实际情况做抉择。我写这篇文章的目的是，读者心中要对问题有本质的理解，看穿本质一切问题都不是问题。
比如下单流程中，有本地事务，订单服务调用，支付单服务调用，优惠券服务调用。
如果使用优惠券失败了(已经被使用了，或者其他原因)，其实我采取的是第二种方式，但是我也不需要进行全部 回滚，我重试调用更新订单接口逻辑删除订单，支付单用户是完全感知不到的，我不需要进行处理，支付中心进行定期清理过期即可。
其实这边又可以有另外一个概念，用户感官一致性，让用户感受到一致，不影响核心业务运行即可。内部的不一致事后解决。
