微服务_分布式事务

本地事务在分布式下的问题

1.远程服务成功了，由于网络故障等原因没有返回，导致本地服务认为远程服务失败

2.当本地服务发送异常，已经执行的远程服务无法感知，不会回滚

本地事务，在分布式环境下只能控制自己的回滚，控制不了其他服务的回滚，所以在分布式环境下需要分布式事务

回顾
事务的隔离级别

		READ UNCOMMITTED  读未提交
			一个事务可以服务另一个未提交的事务提交的数据
 		
 		READ COMMITTED  读已提交(Oracle和SQL Server的默认隔离级别)
 			一个事务可以服务另一个已提交的事务提交的数据，多次读取会造成不一样的结果

		REPEATABLE_READ	可重复读(Mysql默认隔离级别)
 			在同一个事务里，select的结果是事务开始时间点的状态，同样的select操作读到的结果会是一致的
 			但是，会有幻读现象，MySQL的InnoDB引擎可以通过next-key locks机制来避免幻读
 		
 		SERIALIZABLE (序列化)
 			在改隔离级别下的事务都是串行顺序执行的，
 			MySQL数据库的InnoDB引擎会给读操作模式加一把读共享锁，从而避免了脏读，不可重复读和幻读问题

事务的传播行为

1.PROPAGATION_REQUIRED 如果当前没有事务，就创建一个新的事务，如果当前存在事务，就加入该事务
		
2.PROPAGATION_SUPPORTS 如果当前存在事务，就加入该事务,如果当前不存在事务，就以非事务执行
		
3.PROPAGATION_MANDATORY 如果当前存在事务，就加入该事务,如果当前不存在事务，就抛出异常
		
4.PROPAGATION_REQUIRED_NEW 创建新的事务，无论当前存不存在事务，都创建新事务
		
5.PROPAGATION_NOT_SUPPORTED 以非事务方式执行，如果当前存在事务，就把事务挂起
		
6.PROPAGATION_NEVER  以非事务方式执行，如果当前存在事务，就抛出异常
		
7.PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前不存在事务，则执行与PROPAGATION_REQUIRED相同的操作

spring boot 事务关键点
	本地事务失效问题：同一个方法内事务方法互调默认实效，可以使用代理方法解决
	ServiceImpl serviceImpl = AopContext.currentProxy();

分布式事务

	1.CAP定理(原则)
		一致性(Consistency)
			在分布式系统的所有数据备份，在同一时刻是否都有同样的值
		
		可用性(Availability)
			在集群的一部分节点故障后，集群整体是否还能相应客户端的读写请求
						
		分区容错性(Partition tolerance)
			大多是分布式系统都分布在多个子网络。每一个子网络就叫做一个区
			分区容错的意思是：区间通信可能会失败
			
		CAP原则指的是，这三个要素最多只能同时实现两点，不能三者兼顾	
		分区容错在分布式系统中，永远都要满足，一致性和可用性不能同时满足
		只可能有CP和AP
		
	2.分布式系统中实现一致性的算法：raft算法
		Raft算法原理简介：
			每个节点存在3种状态：1.follower(随从)  2.leader(领导)  3.candidate(候选者)

			领导选举
				自选
				
				发送请求让其他节点投票
				
				使用心跳机制维护关系				
				
			日志复制
				在每一次心跳leader将日志发送给其他节点
			
			
			所有的改变都需要经过leader
			在没有选举出leader时，客户端请求集群，都无法提供功能，都会返回不可用状态
			为了保证一致，必须选举出leader
		
	3.BASE理论
		是对CAP理论的延伸，思想是即使无法做到强一致性，但可以适当的采用弱一致性，即最终一致性
		
		BASE是指：
			基本可用(Basically Available)
				基本可用是指在分布式系统出现故障时，允许损失部分可用性(例如响应时间，功能的可用性)
	
			软状态(Soft State)
				软状态是指允许系统存在中间状态，例如数据同步中...
			
			最终一致性(Eventual Consistency)
				最终一致性是指系统中的所有数据副本经过一定时间后，最终能达到一致的状态

分布式事务的解决方案

	1.刚性事务-2PC 二阶提交
	
	2.柔性事务-TCC事务补偿方案
		一阶段prepare
		二阶段commit
		二阶段rollback
		TCC模式是指支持把自定义的分支事务纳入到全局事务的管理中		
	
	3.柔性事务-最大努力通知型方案
		不保证数据一定能通知成功，但会提供可查询操作接口进行核对
	
	4.柔性事务-可靠消息+最终一致性保证
		每一个节点失败，都会往消息队列中发送一个消息，其他节点在接到消息后，执行相应的回滚逻辑

分布式事务框架 Seata
https://seata.io/zh-cn/docs/overview/what-is-seata.html

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。
Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata控制分布式事务
	1.每一个微服务必须先创建undo_log表
	2.安装事务协调器：seata-server
	3.springboot整合Seata，导入依赖 spring-cloud-starter-alibaba-seata
	4.启动seata-server
		4.1 registry.conf配置
	
	5.所有想要用到分布式事务的微服务，都应该使用Seata DataSourceProxy 代理自己的数据源
	
	6.添加注解@GlobalTransaction