分布式事务

1、分布式事务产生的背景：
传统项目中应用了多数据源；
分布式项目，服务与服务之间通讯采用RPC远程调用技术，但是每个服务都有自己独立的数据源，独立的本地事务，服务通讯的时候，两个本地事务在某些时候互不影响，从而出现分布式事务；
a调用b，但是b报错，如果现在终止掉通过判断状态码而判断是否需要抛异常解决事务一致性就不会产生问题；如果a后边的代码报错，则b无法回滚，就会出现问题；

2、CAP与Base理论
C：
Consistency，一致性。在分布式系统中，完成写的操作后任何读的操作都可以读到刚写入的新值；
A:
Availability,可用性，客户端一致可以正常访问并得到系统的正常响应，也就是说服务都会在有限时间内处理完成并作出响应；
P：
Partition Tolerance分区容错性，分布式系统中出现某个节点故障的时候，仍然能够对外提供满足一致性或可用性的服务；

3、柔性事务与刚性事务
Base思想：
Base思想与ACID原理截然不同，它满足CAP原理，通过牺牲一致性获得可用性，一般应用与微服务系统中，通过达到最终一致性来尽量满足业务中的绝大多数需求

Base模型包含如下三个元素：
BA:Basically Available 基本可用
S ：soft state，软状态，状态可以在一段时间内不同步；
E ：Eventually consistent,最终一致，在一定时间内，最终数据达成一致即可；

4、柔性事务和刚性事务
柔性事务满足BASE理论，基本可用，最终一致；
刚性事务满足ACID理论；

5、两阶段与三阶段提交
两阶段提交：
第一阶段提交中协调者会向参与者发送准备通知的，如果参与者接收到通知，都会把该业务逻辑是否执行成功返回给协调者。如果参与者都返回为执行成功，协调者在第二阶段发送提交事务通知，有过有一方执行失败，就会终止提交事务；

三阶阶段提交：
三阶阶段提交就是在两阶段提交上做了改进，增加了询问阶段，协调者询问参与者是否可以完成指令，如果在一定时间内没有返回，就会超时终止，事务进行回滚，有了这个阶段就不会避免由于网络或者服务超时的原因事务得不到事务而导致的数据库问题，

6、jta+atomickos:
JTA是操作java事务的API
Atomickos:Atomikos TransactionsEssentials是一个为Java平台提供的开源的分布式事务管理器框架，这个框架的底层就是转训XA协议开发的，XA事务的基础就是两阶段提交协议；

缺点：这个框架只能在同一个jvm中使用，在微服务中不能使用，所以只是适用于同一个服务中应用了两个数据源的情况；

有时间参考一下https://blog.csdn.net/u013679744/article/details/78674779