分布式事务常见面试题解答

分布式事务有哪些解决方案

1、基于 XA 协议的：两阶段提交和三阶段提交，需要数据库层面支持

2、基于事务补偿机制的：TCC，基于业务层面实现

3、本地消息表：基于本地数据库+mq，维护本地状态（进行中），通过 mq 调用服务，完成后响应一条消息回调，将状态改成完成。需要配合定时任务扫表、重新发送消息调用服务，需要保证幂等

4、基于事务消息：mq

相比两阶段，三阶段有哪些改进

1、两阶段协议：第一阶段（ prepare ） ：每个参与者执行本地事务但不提交，进入 ready 状态，并通知协调者已经准备就绪。

第二阶段（ commit ） 当协调者确认每个参与者都 ready 后，通知参与者进行 commit 操作；如果有参与者 fail ，则发送 rollback 命令，各参与者做回滚。问题：

• 单点故障：一旦事务管理器出现故障，整个系统不可用（参与者都会阻塞住）

• 数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

• 响应时间较长：参与者和协调者资源都被锁住，提交或者回滚之后才能释放

• 不确定性：当协事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。2、三阶段协议：主要是针对两阶段的优化，解决了 2PC 单点故障的问题，但是性能问题和不一致问题仍然没有根本解决引入了超时机制解决参与者阻塞的问题，超时后本地提交，2pc 只有协调者有超时机制

• 第一阶段：CanCommit 阶段，协调者询问事务参与者，是否有能力完成此次事务。如果都返回 yes，则进入第二阶段有一个返回 no 或等待响应超时，则中断事务，并向所有参与者发送 abort 请求

• 第二阶段：PreCommit 阶段，此时协调者会向所有的参与者发送 PreCommit 请求，参与者收到后开始执行事务操作。参与者执行完事务操作后（此时属于未提交事务的状态），就会向协调者反馈“Ack”表示我已经准备好提交了，并等待协调者的下一步指令。

• 第三阶段：DoCommit 阶段， 在阶段二中如果所有的参与者节点都返回了 Ack，那么协调者就会从“预提交状态”转变为“提交状态”。然后向所有的参与者节点发送"doCommit"请求，参与者节点在收到提交请求后就会各自执行事务提交操作，并向协调者节点反馈“Ack”消息，协调者收到所有参与者的 Ack 消息后完成事务。 相反，如果有一个参与者节点未完成 PreCommit 的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送 abort 请求，从而中断事务。

TCC 事务模型

TCC（补偿事务）：Try、Confirm、Cancel 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作 Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作既回滚操作。

TM 首先发起所有的分支事务的 try 操作，任何一个分支事务的 try 操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。

TCC 模型对业务的侵入性较强，改造的难度较大，每个操作都需要有 try 、 confirm 、 cancel 三个接口实现 TCC 中会添加事务日志，如果 Confirm 或者 Cancel 阶段出错，则会进行重试，所以这两个阶段需要支持幂等；如果重试失败，则需要人工介入进行恢复和处理等。