码迷,mamicode.com
首页 > 其他好文 > 详细

微服务-分布式事务解决方案

时间:2019-05-12 00:57:28      阅读:124      评论:0      收藏:0      [点我收藏+]

标签:就是   能力   分布式事务   丢失   消费者   注意事项   锁定   更新   通过   

微服务的搭建

微服务中我们把业务的能力进行了抽象,实际的业务中我们需要用到不同的服务的能力,并且我们处理的业务需要事务的一致性,避免出现数据的紊乱,那么我们就需要对分布式的微服务进行一致性事务的处理。下面是我自己总结的几种方案。

分布式事务解决的方案

一、(XA)两阶段方案

1、先提交每一个(这个是加锁)

2、确认资源,确认每一个RM是否都成功了,判断是否要提交还是要回滚

二、TCC(try-confirm-cancle)两阶段补偿性方案

1、先提交状态为中间状态(数据表更改为更新中,而不是加锁)

2、确认资源,确认每一个RM是否都成功了,都成功了,更新sql的状态,否则回滚

TCC相比于XA的优点

1、TCC是更新数据为中间状态,而两阶段方案是加锁

2、TCC能够对分布式事务中的各个资源进行分别锁定,分别提交与释放,例如,假设有AB 两个操作,假设A操作耗时短,那么A就能较快的完成自身的try-confirm-cancel流程,释 放资源,无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可

3、TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作),也就是各服务之间可以 在一定程度上”异步并行”执行

适用的场景:

1、严格一致性

2、执行时间短

3、实时性要求高

三、异步确认性

通过将一系列同步的事务操作变为基于消息执行异步操作,避免了分布式事务中的同步阻塞 操作的影响。

需要额外说明的一点,就是事务消息投递到MQ定阅方后,并不一定能够成功执行。

需要 MQ订阅方主动给予消费反馈(ack):

1、如果MQ订阅方执行远程事务成功,则给予消费成功的ACK,那么MQ server可以将事务 消息移除;

2、如果执行失败,MQ Server需要对消息重新投递,直至消费成功。

注意事项

1、消息中间件在系统中扮演一个重要的角色,所有的事务消息都需要通过它来传达,所以 消息中间件也需要支持 HAC 来确保事务消息不丢失。

2、根据业务逻辑的具体实现不同,还可能需要对消息中间件增加消息不重复,不乱序等其 它要求。

适用场景

1、执行周期较长

2、实时行要求不高

例如

1、跨行转账/汇款业务(两个服务分别在不同的银行中)

2、退货/退款业务

3、财务,账单统计业务(先发送到消息中间件,然后进行批量记账)

四、最大努力通知型

这是分布式事务中要求最低的一种,也可以通过消息中间件实现,与前面异步确保型操作不 同的一点是,在消息由MQ Server投递到消费者之后,允许在达到最大重试次数之后正常 结束事务。

适用场景

交易结果消息的通知等。

微服务-分布式事务解决方案

标签:就是   能力   分布式事务   丢失   消费者   注意事项   锁定   更新   通过   

原文地址:https://www.cnblogs.com/ricklz/p/10850571.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!