分布式事务

单机事务：

A ：原子性：描述客户端发起多个写操作，假如果其中一些事务发生异常，就会全部进行回滚。
C：一致性：任何数据改变，都不能改变系统恒等状态。
I：隔离性：并发的多个事务相互隔离。（mysql 四种隔离性：读已提交、读未提交、可重复读、可串行化）。
D：持久性：一旦提交，数据就不会丢失。

在宕机时，通过redolog进行单机事务的一致性保证
在出错时，通过undolog进行回滚

---

场景引入：现在订单数据库、支付数据库不是一个服务，现在支付失败的话，怎么进行回滚？假如果订单数据库是MySQL，支付数据库为Oracle呢？

分布式事务：

分布式理论基础

CAP理论：
C 一致性
A 可用性
P 分区容忍性
分布式情况下，P是需要保证的，所以我们可以选择A、C

BASE理论：
基本可用：
最终一致性：
软状态：

一致性三种级别：

强一致性：写入什么，读出什么。
弱一致性：不一定读到最新值。
最终一致性：保证在一定时间内到达最终一致性的状态。

最终一致性举例，京东商城秒杀，你看到商品数量还在，等到你结算的时候发现库存不足，当时商品页看到的库存可能是过时的，不过在此业务场景下并不影响。

读写一致性：从主库读
单调读：从一个库读
因果一致性：写入相同分区

柔性事务与刚性事务

柔性事务：

我们根据自身业务特性，通过适当的方式来保证系统数据的最终一致性。 像 TCC、 Saga、MQ 事务 、本地消息表 就属于柔性事务。
TCC:
https://blog.csdn.net/weixin_42222436/article/details/123133405

刚性事务：

2PC、3PC
XA协议
我们可以利用协调器来协调分布式事务的提交。
事务协调者：（TM-Transcation Manager）
事务参与者：（RM-Resource Manager）

2PC:

准备阶段：协调者询问事务参与者是否执行事务操作，事务参与者返回YES、NO
提交阶段：如果全部回复YES，TM发送Commit消息，事务参与者回复ACK消息，一个失败全局回滚

3PC: