我的世界java版下载地址，附相关架构及资料-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_85407073/article/details/140193155

两套协议

两阶段提交协议2PC

两阶段提交（2PC） 是 Oracle Tuxedo 系统提出的 XA 分布式事务协议的其中一种实现方式。

XA协议中有两个重要角色：事务协调者和事务参与者

漫话图解

2PC协议有两个阶段：Propose和Commit. 在无failure情况下的2PC协议流程的画风是这样的:

• Propose阶段:

￮ coordinator: “昨夜验人有惊喜, 今天都投票出六娃”

￮ voter1/voter2/voter3: “好的女王大人!”

• Commit阶段

￮ coordinator: “投六娃”

￮ voter1/voter2/voter3: “投了女王大人!” (画外音: 六娃扑街)

图1: 2PC, coordinator提议通过, voter{1,2,3}达成新的共识

如果有至少一个voter (比如voter3)在Propose阶段投了反对票, 那么propose通过失败. coordinator就会在Commit(or abort)阶段跟所有voter说, 放弃这个propose.

图2: 2PC, coordinator提议没有通过, voter{1,2,3}保持旧有的共识

具体流程

分布式事务中2PC的具体流程是这样的：

第一阶段

• 顺利的情况

事务协调者的节点会首先向所有的参与者节点发送 Prepare(预备) 请求。
在接到 Prepare(预备) 请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。
参与者执行成功，暂时不提交事务，向事务协调节点返回done(完成)消息。
进入第二阶段

• 出错时

在XA的第一阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

事务协调者的节点会首先向所有的参与者节点发送 Prepare(预备) 请求。
在接到 Prepare(预备) 请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。
参与者执行失败，返回失败消息。
协调者中断事务

中断事务

任何一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事物。

发送回滚请求。协调者向所有参与者节点发出 Rollback 请求。
事物回滚。参与者收到Rollback请求之后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事物执行期间占用的资源。
反馈事物回滚结果。参与者在完成事物回滚之后，向协调者发送 Ack 消息。
中断事务

第二阶段

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

优缺点

优点

2PC是强一致（要打个问号）协议：

预备、提交两个阶段保证了事务是原子的
2PC是允许读-写隔离的，这意味着某个字段的变更在事务协调者提交之前是不可见的。

缺点

同步阻塞：当参与事务者存在占用公共资源的情况，其中一个占用了资源，其他事务参与者就只能阻塞等待资源释放，处于阻塞状态。
单点故障：一旦事务管理器出现故障，整个系统不可用
数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
不确定性：当协事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

三阶段提交协议3PC

漫话图解

简单的说来, 3PC就是把2PC的Commit阶段拆成了PreCommit和Commit两个阶段. 通过进入增加的这一个PreCommit阶段, voter可以得到Propose阶段的投票结果, 但不会commit; 而通过进入Commit阶段, voter可以盘出其他每个voter也都打算commit了, 从而可以放心的commit.

换言之, 3PC在2PC的Commit阶段里增加了一个barrier(即相当于告诉其他所有voter, 我收到了Propose的结果啦). 在这个barrier之前coordinator掉线的话, 其他voter可以得出结论不是每个voter都收到Propose Phase的结果, 从而放弃或选出新的coordinator; 在这个barrier之后coordinator掉线的话, 每个voter会放心的commit, 因为他们知道其他voter也都做同样的计划.

图3: 3PC, coordinator提议通过, voter{1,2,3}达成新的共识

具体流程

阶段一 CanCommit

事务询问：Coordinator 向各参与者发送 CanCommit 的请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应；
参与者向 Coordinator 反馈询问的响应：参与者收到 CanCommit 请求后，正常情况下，如果自身认为可以顺利执行事务，那么会反馈 Yes 响应，并进入预备状态，否则反馈 No。

阶段二 PreCommit

执行事务预提交：如果 Coordinator 接收到各参与者反馈都是Yes，那么执行事务预提交：

发送预提交请求：Coordinator 向各参与者发送 preCommit 请求，并进入 prepared 阶段；
事务预提交：参与者接收到 preCommit 请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日记中；
各参与者向 Coordinator 反馈事务执行的响应：如果各参与者都成功执行了事务操作，那么反馈给协调者 ACK 响应，同时等待最终指令，提交 commit 或者终止 abort，结束流程；

中断事务：如果任何一个参与者向 Coordinator 反馈了 No 响应，或者在等待超时后，Coordinator 无法接收到所有参与者的反馈，那么就会中断事务。

发送中断请求：Coordinator 向所有参与者发送 abort 请求；
中断事务：无论是收到来自 Coordinator 的 abort 请求，还是等待超时，参与者都中断事务。

阶段三 doCommit

执行提交

发送提交请求：假设 Coordinator 正常工作，接收到了所有参与者的 ack 响应，那么它将从预提交阶段进入提交状态，并向所有参与者发送 doCommit 请求；
事务提交：参与者收到 doCommit 请求后，正式提交事务，并在完成事务提交后释放占用的资源；
反馈事务提交结果：参与者完成事务提交后，向 Coordinator 发送 ACK 信息；
完成事务：Coordinator 接收到所有参与者 ack 信息，完成事务。

中断事务：假设 Coordinator 正常工作，并且有任一参与者反馈 No，或者在等待超时后无法接收所有参与者的反馈，都会中断事务

发送中断请求：Coordinator 向所有参与者节点发送 abort 请求；
事务回滚：参与者接收到 abort 请求后，利用 undo 日志执行事务回滚，并在完成事务回滚后释放占用的资源；
反馈事务回滚结果：参与者在完成事务回滚之后，向 Coordinator 发送 ack 信息；
中断事务：Coordinator 接收到所有参与者反馈的 ack 信息后，中断事务。

优缺点

• 优化单点故障：相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务。

• 一致性问题：

四种方案

Saga

1987年普林斯顿大学的Hector Garcia-Molina和Kenneth Salem发表了一篇Paper Sagas，讲述的是如何处理long lived transaction（长活事务）。Saga是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga 模式用一种非常纯朴的方式来处理一致性：补偿。上图左侧是正常的事务流程，当执行到 T3 时发生了错误，则开始执行右边的事务补偿流程，反向执行T3、T2、T1 的补偿服务，其中 C3 是 T3 的补偿服务、C2 是 T2 的补偿服务、C1 是 T1 的补偿服务，将T3、T2、T1 已经修改的数据补偿掉。