建议先关注、点赞、收藏后再阅读。
2PC模型中可能出现的数据不一致问题
在2PC模型中，第一阶段是准备阶段。在这个阶段，协调者向参与者发送准备请求，要求参与者准备进行事务提交。
如果协调者在第一阶段崩溃，以下情况可能发生：
- 参与者等待超时： 参与者可能一直等待协调者的消息，如果协调者崩溃，参与者可能会无限期地等待下去。
- 参与者提交事务： 在第一阶段中，参与者接收到准备请求后，会将事务准备好以等待提交。如果协调者崩溃后，参与者可能会提交自己的事务，因为它无法得知协调者是否要求回滚事务。
由于以上情况，数据不一致的情况是可能发生的。如果协调者崩溃，部分参与者可能已经提交了事务，而其他参与者可能还在等待或者准备回滚事务。这种情况下，数据在不同参与者之间就会不一致。因此，在第一阶段中，协调者的崩溃可能导致数据不一致的情况发生。
3PC对比2PC在性能方面的不一样
三阶段提交相对于二阶段提交带来了更低的性能。
在二阶段提交中，存在着两个阶段：准备阶段和提交阶段。在准备阶段，事务需要向所有的参与者节点发送Prepare请求，并等待所有节点的响应。只有当所有节点都做出了预提交的响应后，事务才能进入提交阶段，此时事务向所有节点发送Commit请求，并等待所有节点的响应。如果存在网络延迟或者其中一个节点故障，整个事务就会被阻塞。
而在三阶段提交中，引入了一个额外的阶段：预提交阶段。在预提交阶段，事务向所有节点发送预提交请求，并等待所有节点的预提交响应。只有当所有节点都做出了预提交的响应后，事务才能进入真正的提交阶段，此时事务向所有节点发送提交请求，并等待所有节点的提交响应。因此，三阶段提交相对于二阶段提交会增加一个额外的网络通信和等待的阶段，从而导致了更低的性能。
三阶段提交的额外阶段增加了事务的处理时间和网络通信的开销。尽管三阶段提交能够解决二阶段提交存在的部分问题（如脑裂问题），但同时也引入了更多的复杂性和潜在的性能损失。因此，在性能要求较高的场景下，相对于二阶段提交，三阶段提交会带来更低的性能。
