分布式事务——《2PC、3PC》数据库层的分布式事务

背景

在微服务架构下。
有时事务并不能在同一台服务器内完成，还得调用其他服务的事务方法，这就是分布式事务。

假如没有经过处理，那就不能保证ACID。
比如原子性:
我的事务方法分别调用了A服务和B服务的修改方法。

1. 事务方法开始；
2. A服务方法$执行成功$;
3. B服务方法$执行失败$;
4. 事务方法结束；
   事务方法结束后，B服务方法失败，但A服务方法没有回滚，显然$不满足原子性$。

这就微服务带来的问题之一。

---

2PC（Two-phase commit protocol）

二阶段提交，引入一个事务协调者来管理参与者（MYSQL）的提交和回滚。
二阶段顾名思义，有两个阶段：

1. 准备阶段：
   • 协调者：向参与者发送准备命令，等待参与者的响应。
   • 参与者: 执行事务，返回响应。
2. 提交/回滚阶段：
   • 协调者: 根据响应向参与者发送提交/回滚请求。
   • 参与者: 执行提交/回滚请求。
     缺点：
     假如网络问题 或 协调者出问题了，参与者事务都已经处理完了，但是无法收到协调者的提交命令，这就导致数据库相关的记录阻塞，其他事务也无法对相关记录进行修改。
     所以就引入的超时机制——3PC。

---

3PC（Two-phase commit protocol）

1. 准备阶段：
   • 协调者：向参与者发送准备命令，等待参与者的响应。
   • 参与者: 返回响应, 表示可以执行事务。。
2. 预提交阶段
   • 协调者: 向参与者发送预提交请求，进入预提交阶段。
   • 参与者：执行事务后返回ACK响应，同时等待最终指令。同时加入超时机制。
3. 提交/回滚阶段
   • 协调者: 接收到所有参与者的ACK响应之后，根据响应向参与者发送提交/回滚请求。
   • 参与者: 执行提交/回滚请求。

注意： 2PC 和 3PC 都不能保证数据100%一致，因此一般都需要有定时扫描补偿机制