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

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阶段的缺点