分布式事务方案

数据库事务acid
cap理论
	consistency(强)一致性,读取必须最新的数据
	availability可用性
	partition tolerance分区容忍(分布式基本条件)
	
	一般使用ap组合,base理论是ap的扩展,不需要强一致性,只要最终一致性
分布式事务
	2pc(两阶段提交协议,prepare commit)
		XA方案
			1TM通知各个RM执行业务,RM执行,并未提交,资源锁定
			2TM收到回复,只要有失败则通知其他RM回滚,资源释放
			3TM收到回复若都成功,通知其他RM提交,资源释放
                缺点:
				需要本地数据库直持XA协议
				资源锁定,性能较差
		Seata的AT模式(还有TCC,不支持spring cloud)
			TC(Transaction Coordinator)事务协调器,独立部署运行的中间件,接受TM指令,维护全局事务状态,鱼RM通信协调分支事务提交回滚
			TM(Transaction Manager)事务管理器,嵌入应用程序中,负责开启全局事务,最终向TC发起全局提交回滚指令
			RM(Recource Manager)控制分支事务,负责分支注册,状态汇报,接受TC指令,驱动分支事务提交或回滚
			1TM向TC申请创建全局事务
			2RM向TC注册分支事务,TM执行业务(已经提交),并向TC发送全局提交或回滚决议
			3TC完成提交或者回滚请求
			使用
				全局事务开始使用@GrobalTransaction
				每个分支事务仍然要@Transaction
				需要创建undo_log表,保证事务一致性的关键
				
	tcc业务层面(try confirm cancel try之后就确认了资源可用与否,然后confirm cancel要成功完成,否则重试,)
		hmily
			不需要中间件独立部署(事务协调服务),但是需要数据库如mysql来进行日志存储
			支持dubbo,springcloud RPC框架
			本地事务存储支持redis mongodb zookeeper mysql
			问题:
				空回滚:没有执行try,就去执行cancel,解决:try插入一条记录,否则没有记录,cancel判断有没有记录再回滚
				幂等:try之后confirm或cancel执行多次,解决:confirm判断是否有记录,有则执行并插记录,否则跳过
				悬挂:confirm和cancel比try先执行,解决:
	消息队列
		异步通信
	at
	tcc
	saga