分布式事务的全套解决方案

2021年6月23日 9点热度 0条评论 来源: log.info(小吕同学)
1.事务我们大家都知道就是一组逻辑运算 要么同时成功要么同时失败.
我们在单体项目中通过spring的@transaction 可以控制事务
呢么在分布式系统中事务是怎么控制的呢
2.分布式事务就是说2个服务的调用或者多个服务的调用,他们的操作或者说执行逻辑要么同时成功或者同时失败
在微服务分布式项目中 一个请求进来,落到一个服务上,这个服务可能需要调用多个服务来完成业务逻辑
3. 在分布式系统中,一个请求要完成一整个事情,可能一个服务完不了, 需要多个服务的共同完成.
 比方说下单请求 1.你可能要调用库存服务 减库存
			  2. 需要调用订单服务 创建订单
			  3. 调用用户服务 看有没有权限
			  4. 需要调用积分服务 去加个积分
			  5. 去调用物流服务准备发货



https://www.cnblogs.com/dyzcs/p/13780668.html
参考博客
2阶段提交
	分布式事务中引入一个事务协调者的角色,2阶段提交 分2个阶段
	第一个阶段叫做准备或者投票阶段
	2个服务此时只是执行了sql,但是没有做最后的commit, 也就是最终没有落库,这就是第一个阶段要做的事情,就是说我去尝试一下/update 看能否成功 如果可以成功的 我给协调者一个反馈表示成功, 如果不能的话 我也给协调者一个反馈表示不成功,

2阶段的第一个阶段 每个服务都向协调者反馈同意时候,也就是说2阶段第一阶段执行都没问题的话,呢么第二阶段事务协调者就会下发commit的命令,因为你刚刚执行的sql没有进行commit操作,这次给你下达指令,让你去执行commit 
A服务执行commit B 服务也去执行commit 
执行完毕之后再反馈结果

这样就完成事务 这就保证了 2个服务要么全部执行 要么都不执行
如果一个请求先调用了a  再调用了b 这样是无法保证要么全部执行 要么全部不执行
中间加个协调者  这样看起来可以保证2个服务的事务

如果在2阶段提交的第一个阶段 有一个服务给协调者反馈失败,或者协调者在规定时间内没有等到参与者的反馈呢么,在第二阶段就会下发rollback指令, 让服务进行回滚操作


2阶段提交协议 
2个阶段 第一先去尝试提交 让每个服务先执行一次 不进行commit操作  ,然后你们吧执行的结果反馈给协调者
协调者统一收集你们的结果之后 再决定你们每个服务是提交还是回滚
这就是2阶段提交的整体流程
2阶段提交的缺点
	第一就是单点故障,协调者挂了,服务不知道数据执行完向谁反馈,也没人来发送要么提交/回滚的指令
	第二就是阻塞资源 ,比如说a服务执行insert操作 在第一阶段反馈给协调者 成功, [此时他是不能够释放连接的 ] 第二阶段 协调者下达commit操作,如果他在第一阶段释放了数据库连接, 第二个阶段 协调者下发commit的时候还能正常提交么
第三点就是 TM 在第一阶段 2个服务都给tm 反馈ok, tm向
 serverA 发送一个指令 commit 也向serverB 发送一个指令commit
结果 serverA 收到commit 把数据改了 落库了, 发给serverB 的commit 半路上网络丢了 ,
serverB 就不知道该提交还是回滚
他就会一直等 如果等的话, 程序员发现这个服务卡在这里
重启 , 当重启完毕发现 serverA 数据改了,serverB 数据没改 
所以就会造成数据不一致,这就是2阶段的缺点

    原文作者:log.info(小吕同学)
    原文地址: https://blog.csdn.net/weixin_43689953/article/details/118078743
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。