微服务中分布式事务有哪些解决方案?

提问者:帅平 问题分类:微服务
微服务中分布式事务有哪些解决方案?
4 个回答
宁愿短发披肩
宁愿短发披肩
第四种解决方案:TCC事务
TCC即为Try Confirm Cancel,它属于补偿型分布式事务。TCC实现分布式事务一共有三个步骤:
Try:尝试待执行的业务
这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源

Confirm:确认执行业务
确认执行业务操作,不做任何业务检查, 只使用Try阶段预留的业务资源。通常情况下,采用TCC则认为 Confirm阶段是不会出错的。即:只要Try成功,Confirm一定成功。若Confirm阶段真的出错了,需引入重试机制或人工处理。

Cancel:取消待执行的业务
取消Try阶段预留的业务资源。通常情况下,采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了,需引入重试机制或人工处理

整个TCC事务处理流程如下:
发布于:1年前 (2023-04-13) IP属地:四川省
你以为我的心是不锈钢么
你以为我的心是不锈钢么
第三种解决方案:最大努力通知
最大努力通知也被称为定期校对,其实是对第二种解决方案的进一步优化。它引入了本地消息表来记录错误消息,然后加入失败消息的定期校对功能,来进一步保证消息会被下游系统消费。

最大努力通知的流程如下:
第一步: 消息由系统A投递到中间件
1. 处理业务的同一事务中,向本地消息表中写入一条记录
2. 准备专门的消息发送者不断地发送本地消息表中的消息到消息中间件,如果发送失败则重试

第二步: 消息由中间件投递到系统B
1. 消息中间件收到消息后负责将该消息同步投递给相应的下游系统,并触发下游系统的任务执行
2. 当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该条消息删除,从而该
事务完成
3. 对于投递失败的消息,利用重试机制进行重试,对于重试失败的,写入错误消息表
4. 消息中间件需要提供失败消息的查询接口,下游系统会定期查询失败消息,并将其消费
发布于:1年前 (2023-04-13) IP属地:四川省
孑身一人
孑身一人
第二种解决方案:可靠消息服务
基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。假设有A和B两个
系统,分别可以处理任务A和任务B。此时存在一个业务流程,需要将任务A和任务B在同一个事务中处
理。就可以使用消息中间件来实现这种分布式事务。

可靠消息服务的整个流程如下:
一、消息由A系统投递到消息中间件

二、消息由中间件投递到系统B
发布于:1年前 (2023-04-13) IP属地:四川省
细腻长发姐
细腻长发姐
第一种解决方案:全局事务
全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色:
AP: Application 应用系统 (微服务)
TM: Transaction Manager 事务管理器 (全局事务管理)
RM: Resource Manager 资源管理器 (数据库)

整个事务分成两个阶段
阶段一: 表决阶段,所有参与者都将本事务执行预提交,并将能否成功的信息反馈发给协调者。
阶段二: 执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地执行提交或者回滚

整个流程如下图:

全局事务的优点有:
提高了数据一致性的概率,实现成本较低

全局事务的缺点有:
单点问题: 事务协调者宕机
同步阻塞: 延迟了提交时间,加长了资源阻塞时间
数据不一致: 提交第二阶段,依然存在commit结果未知的情况,有可能导致数据不一致
发布于:1年前 (2023-04-13) IP属地:四川省
我来回答