分布式系统架构( 四 ) _分布式

总结: 各个参与者进行投票是否让事务进行
阶段二
1. 发送提交请求：协调者向所有参与者发出 commit 请求。
2. 事务提交：参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
3. 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。
4. 完成事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务
场景二执行失败事务中断流程

文章插图

阶段一也是准备阶段，跟成功时候的准备阶段一致。
阶段二
1. 发送回滚请求：协调者向所有参与者发出 Rollback 请求。
2. 事务回滚：参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送 Ack 信息。
4. 中断事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。
1.7.3 2PC总结优点：原理简单，实现方便。
缺点：同步阻塞，单点问题，数据不一致，过于保守
同步阻塞：二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题：协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致：假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
过于保守：如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
1.8一致性协议3PC1.8.1概念3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

文章插图

1.8.2 3PC流程说明阶段一CanCommit① 事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
② 各参与者向协调者反馈事务询问的响应：参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

文章插图

阶段二：PreCommit协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务假如所有参与反馈的都是Yes，那么就会执行事务预提交。
执行事务的话分为3个步骤：
① 发送预提交请求：协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
② 事务预提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
③ 各参与者向协调者反馈事务执行的结果：若参与者成功执行了事务操作，那么反馈Ack
如果任何一个参与者反馈了No响应之后则就会中断事务。
中断事务分为2个步骤：
① 发送中断请求：协调者向所有参与者发出abort请求。
② 中断事务：无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务。
阶段三：do Commit