1，分布式事务产生的背景。
分情况而定
1， 在单体的项目中，多个不同的业务逻辑都是在同一个数据源中实现事务管理，是不存在分布式事务的问题，因为同一个数据源的情况都是采用事务管理器，相当于每个事务管理器对应一个数据源。
[图片上传失败...(image-810669-1618491127348)]
2，在单体的项目中，有多个不同的数据源，每个数据源都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理： 解决方案 jta+Atomikos
[图片上传失败...(image-7df061-1618491220423)]
3，在分布式/微服务架构中，每个服务都有自己的本地事务，每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。
事务的定义：
对我们的业务逻辑可以实现提交或者回滚，保证数据的一致性的情况。
所以要么提交，要么回滚
原子性a 要么提交 要么回滚
一致性c
隔离性i 多个事务在一起执行的时候，互不影响；
持久性d 事务一旦提交或者回滚后，不会在对该结果有任何影响
2，传统分布式事务解决方案
3，2PC/3PC协议使用场景。
4，LCN为什么不更新了？那些思想值得学习、
5，分布式事务解决方案有哪些？
6，强一致性/最终一致性区别。
7，LCn深度源码解读。
CAP理论
1 CAP定律和BASE理论
1.1 CAP定律#
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
（一）一致性（C）
在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
（二）可用性（A）
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
（三）分区容错性（P） 形成脑裂问题
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
https://baike.baidu.com/item/%E5%AE%B9%E9%94%99%E7%8E%87/9967698?fr=aladdin
（四）总结一下
以上可以知道分区容错性（P）主要代表网络波动产生的错误，这是不可避免的，且这个三个模式不可兼得，所以目前就只有两种模式：CP和AP模式。
其中CP表示遵循一致性原则，但不能保证高可用性，其中zookeeper作为注册中心就是采用CP模式，因为zookeeper有过半节点不可以的话整个zookeeper将不可用。
AP表示遵循于可用性原则，例如Eureka作为注册中心用的是AP模式，因为其为去中心化，采用你中有我我中有你的相互注册方式，只要集群中有一个节点可以使用，整个eureka服务就是可用的，但可能会出现短暂的数据不一致问题。
AP保证可用性：但是不能保证每个副本数据数据一致性；
CP保证数据一致性：如果有过半的zk节点宕机的情况下，不能保证可用性，但是必须保证每个副本节点之间数据一致性， 比如ZK；
Base理论
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
（一）基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，注意，这绝不等价于系统不可用。
比如：响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒。
系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
（二）软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
（三）最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
目前主流分布式解决框架：
1，单体项目多数据源，可以jta+Atomikos
2,基于RabbitMQ的形式解决，最终一致性的思想。
3，基于RocketMQ解决分布式事务，采用事务消息。
4，LCn采用lcn模式，假关闭连接
5,Alibaba的Seata
6，跨语言的方式实现解决分布式事务问题，类似于支付宝回调。
俩阶段提交协议基本概念：
2阶段提交协议可以理解为2pc，也就是分为参与者和协调者，协调者会通过2次阶段实现数据最终一致性。
2pc和3pc的区别就是解决参与者超时的问题和多加了一层询问，保证数据的传输可靠性。
简单的回顾一下LCN解决分布式事务
LCN官网基本介绍
http://www.txlcn.org/zh-cn/ LCN并不生产事务，LCN只是本地事务的协调工
现在官网已经不维护呢，可以参考：GitEE
https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search
默认密码为：codingapi
lcn基本实现处理：
1，发起方与参与方都与我们的lcn管理器一直保持长连接；
2，发起方在调用接口前，先向lcn管理器中申请一个全局的事务分组id.
3,发起方调用接口的时候在请求头中传递事务分组id
,4参与方获取到请求头中有事务分组的id的，则当前业务逻辑执行完实现假关闭，不会提交或者回滚事务‘
5，发起方调用完接口后，如果出现异常的情况下，在通知给事务回滚事务，这时候事务协调则告诉参与方回滚当前的事务。
lcn解决分布式事务的原理：
角色划分：
1，全局事务协调者（组长）；
2，发起方--调用接口者
3，参与方--被别人调用接口。
订单（发起方）调用派单（参与方）
1.发起方和参与方都会与我们的全局事务协调者保持长连接；
- 订单（发起方）连接到我们全局事务协调者，先生成一个事务全局的分组id
- 当我们发起方调用接口的时候，会再请求头中设置该事务全局分组id；
- 参与方从请求头中获取到该全局分组id，这是我们的数据源就不会提交。
- 发起方调用参与方接口完毕之后，如果报错或者没有问题的情况下，都会发送
一个通知给事务协调者，通知给其他的参与方到底是回滚还是提交。
LCN实现分布式事务方案：有可能会引发行锁问题
整合和源码解读。
SpringBoot整合lcn5.0
Maven依赖
<dependency>
<groupId>com.codingapi.txlcn</groupId>
<artifactId>txlcn-tc</artifactId>
<version>5.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>com.codingapi.txlcn</groupId>
<artifactId>txlcn-txmsg-netty</artifactId>
<version>5.0.2.RELEASE</version>
</dependency>
相关配置
tx-lcn:
client:
manager-address: 127.0.0.1:8070
logger:
enabled: true
参与方获取全局id
1.SpringTracingApplier
拦截器 获取feign客户端请求头中的参数全局事务分组id，缓存到threadlocal中。
- Aop的重写的入口TransactionAspect
- 事务不会提交 暂时假关闭。
- DataSourceAspect##LcnConnectionProxy
基于代理数据源的形式 直接重写了原生的了sql连接 注释掉 commit方法
