面试题：分布式系统故障场景下ACID一致性的维护

在分布式系统中，为保证正在进行的数据库事务满足ACID一致性，需要通过协调机制来确保所有参与节点对事务的处理达成一致。常见方法包括基于投票的协议（如2PC和3PC），以及使用Paxos、Raft等一致性算法。这些机制通过消息传递和状态协调，在故障发生时能够回滚或提交事务，保证数据一致性。

第一阶段（投票阶段）：协调者向所有参与者发送Prepare消息，参与者检查自身是否能够执行事务操作。如果可以，返回Yes响应，进入就绪状态；否则返回No响应。
第二阶段（提交/回滚阶段）：
- 提交：若所有参与者都返回Yes，协调者发送Commit消息，参与者接收到后提交事务。
- 回滚：若有任何一个参与者返回No，或者协调者在第一阶段未收到所有参与者的响应，协调者发送Abort消息，参与者接收到后回滚事务。
故障恢复：
- 协调者故障：参与者在等待协调者决策时，若超时未收到消息，会进入阻塞状态。此时需要引入恢复机制，如通过选举新的协调者，新协调者询问所有参与者状态，根据多数参与者的状态决定事务是提交还是回滚。
- 参与者故障：若参与者在第一阶段故障，不影响其他参与者，因为协调者只需收到多数参与者的响应。若在第二阶段故障，恢复后需查询协调者或其他参与者状态，以确定事务最终状态是提交还是回滚。

第一阶段（CanCommit阶段）：协调者向参与者发送CanCommit消息，参与者检查自身是否可以执行事务操作，若可以返回Yes响应，否则返回No响应。
第二阶段（PreCommit阶段）：
- 若所有参与者返回Yes：协调者发送PreCommit消息，参与者接收到后进入预提交状态，并锁定资源。
- 若有参与者返回No：协调者发送Abort消息，参与者接收到后回滚事务。
第三阶段（DoCommit阶段）：
- 提交：协调者发送DoCommit消息，参与者接收到后正式提交事务。
- 回滚：若协调者在第二阶段未收到所有参与者的响应，或超时，会发送Abort消息，参与者回滚事务。
故障恢复：
- 协调者故障：由于3PC有预提交阶段，参与者在预提交后不会像2PC那样长时间阻塞。新协调者选举后，若参与者处于预提交状态，可根据超时等情况决定是否提交事务（一般超时后提交）。若参与者处于初始状态（未进入预提交），则按正常流程处理。
- 参与者故障：若参与者在第一阶段故障，类似2PC处理。若在第二阶段故障，恢复后若处于预提交状态，可根据超时决定提交事务；若未进入预提交状态，按正常流程。

优点：
- 简单：协议相对简单，易于理解和实现。
- 广泛应用：在很多分布式数据库中广泛使用，如传统的Oracle RAC等。
缺点：
- 单点故障：协调者是单点，一旦故障，参与者可能长时间阻塞。
- 同步阻塞：参与者在第一阶段后需等待协调者决策，期间资源锁定，影响并发性能。
- 脑裂问题：若协调者与部分参与者网络分区，可能导致部分参与者提交事务，部分回滚，破坏数据一致性。

优点：
- 减少阻塞：预提交阶段减少了参与者的阻塞时间，提高了系统的可用性。
- 相对健壮：在一定程度上解决了2PC的单点故障和脑裂问题，增强了系统的健壮性。
缺点：
- 复杂性增加：相比2PC，3PC引入了更多的消息交互和状态管理，实现更为复杂。
- 性能开销：由于增加了消息交互，在正常情况下也会带来一定的性能开销。

星途面试题库