没事总结下2PC

过程简述：

第一阶段

1. 事务询问： 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作， 并开始等待各个参与者的响应
2. 事务执行： 各个参与者执行事务操作， 并将undo 和redo（要redo信息干嘛, 节点重启之后重做？ ）信息记入事务日志中
3. 各参与者向协调者反馈事务询问的响应，YES/NO

第二阶段（执行事务提交/中断事务）

执行事务提交（假如协调者收到的都是YES)

1. 发送提交请求： 协调者向所有参与者发送commit请求
2. 事务提交：参与者在收到commit请求后，会正式执行事务提交操作，并在提交完成后释放整个事务执行期间所占有的资源
3. 反馈事务提交结果：参与者在完成事务提交之后， 想协调者发送ACK请求
4. 协调者接受到所有参与者反馈的ACK后，完成事务

中断事务（假如任何一个参与者向协调者反馈NO后， 或者在等待超时之后，协调者无法接受到所有参与者的响应，那么就中断事务）

1. 发送回滚请求：协调者向所有的参与者节点发rollback请求
2. 事务回滚：参与者接收到rollback请求后， 会利用第一阶段记录的undo信息来执行事务操作的回滚，并在回滚之后释放整个事务执行期间所占用的资源
3. 反馈事务回滚结果：参与者在事务回滚之后，向协调者发送ACK信息
4. 中断事务：协调者接收到所有参与者反馈的ACK之后， 完成事务中断

优缺点：

优点：原理简单， 实现方便
缺点：同步阻塞，单点问题， 脑裂， 太过保守

同步阻塞：在两个阶段执行的过程中，所以参与该事务操作的逻辑都出于阻塞状态， 从而无法进行任何操作
单点问题：协调者是单点，如果协调者在阶段二出现问题，那么其他的参与者将会一直出于锁定事务资源状态中..
数据不一致： 在阶段二，如果发生局部网络异常或者协调者尚未发送完所有的commit请求之前奔溃， 导致只有部分参与者收到了commit的提交， 那么就会发生数据不一致
太过保守： 如果协调者在询问是否可以提交的时候， 参与者出现故障而协调者始终无法获取到所有参与者的响应信息的话，这时候协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略太过保守。 也就是没有一套完善的容错机制， 任何一个节点的失败都会导致整个事务的失败