二阶段提交为什么会同步阻塞?
二阶段提交为什么会同步阻塞?
月伴飞鱼柔性事务
柔性事务主要分为补偿型和通知型。
补偿型事务分：TCC、Saga。
通知型事务分：MQ事务消息、最⼤努⼒通知型。
补偿型事务都是同步的，通知型事务都是异步的。
二阶段提交（2PC）算法：
在该分布式系统中，存在一个节点作为协调者（Coordinator），其他节点作为参与者（Participants），且节点之间可以进行网络通信。
所有节点都采用预写式日志，日志被写入后被保存在可靠的存储设备上，即使节点损坏也不会导致日志数据的丢失。
所有节点不会永久性损坏，即使损坏后仍然可以恢复。
两阶段提交中的两个阶段，指的是 Commit-Request 阶段和 Commit 阶段，两阶段提交的流程如下。
提交请求阶段（Commit-Request）
在提交请求阶段，协调者将通知事务参与者准备提交事务，然后进入表决过程。
在表决过程中，参与者将告知协调者自己的决策：
- 同意（事务参与者本地事务执行成功）或取消（本地事务执行故障），在第一阶段，参与节点并没有进行Commit操作。
提交阶段（Commit）
在提交阶段，协调者将基于第一个阶段的投票结果进行决策。
提交或取消这个事务，这个结果的处理和前面基于半数以上投票的一致性算法不同，必须当且仅当所有的参与者同意提交。
- 协调者才会通知各个参与者提交事务，否则协调者将通知各个参与者取消事务。
参与者在接收到协调者发来的消息后将执行对应的操作，也就是本地 Commit 或者 Rollback。
两阶段提交存在的问题：
资源被同步阻塞:
在执行过程中，所有参与节点都是事务独占状态，当参与者占有公共资源时，那么第三方节点访问公共资源会被阻塞。
协调者可能出现单点故障:
一旦协调者发生故障，参与者会一直阻塞下去。
在 Commit 阶段出现数据不一致:
在第二阶段中，假设协调者发出了事务 Commit 的通知，但是由于网络问题该通知仅被一部分参与者所收到并执行 Commit。
其余的参与者没有收到通知，一直处于阻塞状态，那么，这段时间就产生了数据的不一致性。
