内容概要
- 分布式事务是什么
- 解决分布式事务的前提理论
- 分布式事务的解决方案
分布式事务是什么
对后端开发者来说都知道什么是事务，事务的四大特性又是什么。（所谓事务就是一组数据的操作，要么都成功要么都失败。事物的四大特性：ACID,原子性、隔离性、一致性、持久性。具体的也就不在阐述了）。 那么分布式事务又是什么？其实分布式事务就是多个小的事务组成的（如一个操作需要同一个服务不同数据源，不同服务同一个数据源 ，不同服务不同数据源等数据改变的一致性），说白了解决分布式事务问题就是解决数据的一致性问题。
解决分布式事务的前提理论
解决分布式事务问题需要知道两个理论知识：CAP定理和BASE理论。 CAP定理：一致性、可用性、分区容错性这三个特性在分布式事务中不能同时满足，也就是说只能满足CA\AP\CP其中的两个，但是在分布式中P(分区容错性)受到硬件的限制，我们不得不保留P，所以在解决分布式事务的时候我们需要根据业务的需求要在一致性和可用性之间舍弃一个。 BASE理论：基本可用、软状态、最终一致性，允许系统存在中间状态，保证系统的基本可用。
分布式事务的解决方案
两阶段提交方案
sequenceDiagram
事务协调者->>事务参与者集群: 询问各个事务参与者是否可以执行
事务参与者集群->>事务参与者集群: 各自执行各自的事务，但不提交
事务参与者集群-->>事务协调者: 返回协调者成功或失败
事务协调者->>事务参与者集群: 如果都是成功，通知提交事务，只要有一个参与者失败，则通知回滚
两阶段提交的缺点：
- 两阶段提交是数据强一致性，在数据执行到数据之间数据是有锁存在的，如果总的业务处理时间比较长的话，总体性能就会受到影响
- 两阶段提交也会受单点故障影响，因为两阶段提交需要一个协调者，如果在第二阶段由于故障没有及时通知参与者，参与者就一直处于未提交和未回滚状态。
TCC（补偿型分布式事务）
TCC的核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿的操作。 分为三个操作：
- Try:这个操作对各个服务的资源做检测以及对资源进行锁定或预留
- Confirm: 执行真正的业务操作，不做任何业务检查只是用try阶段预留的业务资源，confirm操作要求具备幂等设计，confirm失败后需要进行重试；
- Cancel: 如果任何一方检测失败，就会通知所有的进行补偿，释放try阶段预留的业务资源，Cancel操作要求也是要求幂等设计，cancel失败后需要进行重试 优点：性能与2PC要高一些 缺点：TCC对业务侵入性太强，事务补偿就需要自己写大量的代码实现
可靠消息最终一致性方案
其实我个人认为，如果你的业务对一致性没有太严格的要求的话，用可靠消息来实现最终一致性是最方便的，只要你能保证这个消息能不丢失，大概率下都能保证最终的一致性。
