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

本文正在参与【[ 一起秋招吧 ] 】 征文活动，一起来聊聊校招的那些事吧，牛客周边和百元京东卡等你来领~

大家好，我是小羽，专注于后端开发相关知识的分享。今天将给大家带来的是关于后端面试关于分布式事务常考察的必备知识点。

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

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 阶段出错，则会进行重试，所以这两个阶段需要支
持幂等；如果重试失败，则需要人工介入进行恢复和处理等。