面试题：微服务架构下如何通过分布式事务实现数据一致性

准备阶段（投票阶段）：协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者回复。参与者收到请求后，执行事务操作，记录undo和redo日志，但不提交事务，然后向协调者反馈事务操作的结果（同意或不同意提交）。
提交阶段（执行阶段）：如果所有参与者都同意提交（收到所有参与者“同意”的反馈），协调者向所有参与者发送提交事务的指令，参与者收到指令后正式提交事务，并释放事务执行期间占用的资源。如果有任何一个参与者反馈不同意提交，协调者向所有参与者发送回滚事务的指令，参与者根据undo日志回滚事务到初始状态，并释放资源。

优点：原理简单，实现方便，能够保证强一致性。
缺点：
- 单点故障：协调者一旦出现故障，整个系统将无法正常工作。如果在准备阶段协调者崩溃，参与者会一直处于锁定资源状态，直到超时；如果在提交阶段协调者崩溃，部分参与者可能已经提交事务，部分可能未提交，导致数据不一致。
- 同步阻塞：在整个2PC过程中，参与者在等待协调者指令期间，会一直持有资源并处于阻塞状态，无法处理其他事务，影响系统并发性能。
- 数据不一致：在提交阶段，如果协调者发送的指令部分参与者成功接收，部分未成功接收，会导致数据不一致。

CanCommit阶段：协调者向参与者发送CanCommit请求，询问是否可以进行事务提交。参与者检查自身状态，如果可以提交事务，就返回Yes响应，否则返回No响应。这个阶段主要是对参与者的资源可用性等进行预检查。
PreCommit阶段：如果协调者收到所有参与者的Yes响应，向所有参与者发送PreCommit请求，参与者收到该请求后，执行事务操作，记录undo和redo日志，但不提交事务，然后向协调者反馈事务执行的结果（成功或失败）。如果有任何一个参与者返回No响应或者在规定时间内没有收到所有参与者的响应，协调者向所有参与者发送Abort请求，参与者回滚事务。
DoCommit阶段：如果协调者收到所有参与者在PreCommit阶段的成功反馈，向所有参与者发送DoCommit请求，参与者收到请求后正式提交事务，并释放事务执行期间占用的资源。如果有任何一个参与者在PreCommit阶段反馈失败或者在规定时间内没有收到所有参与者的反馈，协调者向所有参与者发送Abort请求，参与者回滚事务。

优点：
- 降低单点故障影响：相比2PC，3PC引入了CanCommit阶段，在一定程度上降低了协调者单点故障的影响。即使协调者在PreCommit阶段崩溃，参与者因为有CanCommit阶段的预检查，可以自行决定是否继续提交事务，减少资源长时间锁定的情况。
- 减少同步阻塞：由于CanCommit阶段的预检查，在PreCommit阶段参与者等待协调者指令的时间相对2PC有所减少，一定程度上提高了并发性能。
缺点：
- 实现复杂：相比2PC，3PC增加了一个阶段，整体流程更为复杂，实现难度加大。
- 依然存在数据不一致风险：虽然降低了数据不一致的概率，但在网络异常等极端情况下，如DoCommit指令部分参与者成功接收，部分未成功接收，还是可能导致数据不一致。

Try阶段：主要是对业务资源进行初步的预留操作，检查业务资源的可用性，完成一些前置条件的检查和资源的锁定，但不真正执行业务操作。例如在支付场景中，Try阶段可以冻结账户资金。
Confirm阶段：如果Try阶段所有操作都成功，那么执行真正的业务操作，对Try阶段锁定的资源进行确认使用。如在支付场景中，将冻结的资金进行实际扣除。
Cancel阶段：如果Try阶段任何一个操作失败，或者在后续流程中出现异常，需要对Try阶段预留的资源进行释放，撤销之前的操作。如在支付场景中，解冻之前冻结的资金。

优点：
- 高性能：TCC不需要像2PC、3PC那样长时间锁定资源，参与者在Try阶段完成后就可以释放部分资源，提高了系统的并发性能。
- 柔性事务：适合高并发场景下的业务，对于一些允许最终一致性的业务场景有较好的适应性，因为它不追求强一致性，而是通过业务补偿机制来保证最终数据的一致性。
缺点：
- 侵入性强：需要业务代码实现Try、Confirm和Cancel三个方法，对业务代码的侵入性较大，增加了业务开发的复杂度。
- 实现难度大：每个业务场景都需要根据自身逻辑编写这三个方法，且需要保证幂等性（重复调用不会产生额外影响），实现难度较高。如果幂等性处理不当，可能会导致数据不一致。

星途面试题库