分布式事务常见解决方案

·  阅读 1130
分布式事务常见解决方案

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第16天,点击查看活动详情

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

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

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

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

4、基于事务消息:mq

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

两阶段协议

第一阶段( prepare ) :每个参与者执行本地事务但不提交,进入 ready 状态,并通知协调者已经准 备就绪。

第二阶段( commit ) 当协调者确认每个参与者都 ready 后,通知参与者进行 commit 操作;如果有 参与者 fail ,则发送 rollback 命令,各参与者做回滚。

问题

  • 单点故障:一旦事务管理器出现故障,整个系统不可用(参与者都会阻塞住)
  • 数据不一致:在阶段二,如果事务管理器只发送了部分 commit 消息,此时网络发生异常,那么 只有部分参与者接收到 commit 消息,也就是说只有部分参与者提交了事务,使得系统数据不一 致。
  • 响应时间较长:参与者和协调者资源都被锁住,提交或者回滚之后才能释放
  • 不确定性:当协事务管理器发送 commit 之后,并且此时只有一个参与者收到了 commit,那么当 该参与者与事务管理器同时宕机之后,重新选举的事务管理器无法确定该条消息是否提交成功。

三阶段协议

主要是针对两阶段的优化,解决了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 阶段出错,则会进行重试,所以这两个阶段需要支 持幂等;如果重试失败,则需要人工介入进行恢复和处理等。

分类:
后端
收藏成功!
已添加到「」, 点击更改