篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了90 SpringCloud 解决分布式事务--lcn解决分布式事务相关的知识，希望对你有一定的参考价值。
参考技术A
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深度源码解读。
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是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的区别就是解决参与者超时的问题和多加了一层询问，保证数据的传输可靠性。
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.发起方和参与方都会与我们的全局事务协调者保持长连接；
SpringBoot整合lcn5.0
Maven依赖
相关配置
参与方获取全局id
1.SpringTracingApplier
拦截器 获取feign客户端请求头中的参数全局事务分组id，缓存到threadlocal中。
不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一种方法同样可以解决分布式事务问题, 并且性能较好, 这就是我这篇文章要介绍的使用事件,本地事务以及消息队列来实现分布式事务.
我们从一个简单的实例入手. 基本所有互联网应用都会有用户注册的功能. 在这个例子中, 我们对于用户注册有两步操作:
1. 注册成功, 保存用户信息.
2. 需要给用户发放一张代金券, 目的是鼓励用户进行消费.
如果是一个单一架构应用, 实现这个功能非常简单: 在一个本地事务里, 往用户表插一条记录, 并且在代金券表里插一条记录, 提交事务就完成了. 但是如果我们的应用是用微服务实现的, 可能用户和代金券是两个独立的服务, 他们有各自的应用和数据库, 那么就没有办法简单的使用本地事务来保证操作的原子性了. 现在来看看如何使用事件机制和消息队列来实现这个需求.(我在这里使用的消息队列是kafka, 原理同样适用于ActiveMQ/RabbitMQ等其他队列)
我们会为用户注册这个操作创建一个事件, 该事件就叫做用户创建事件(USER_CREATED). 用户服务成功保存用户记录后, 会发送用户创建事件到消息队列, 代金券服务会监听用户创建事件, 一旦接收到该事件, 代金券服务就会在自己的数据库中为该用户创建一张代金券. 好了, 这些步骤看起来都相当的简单直观, 但是怎么保证事务的原子性呢? 考虑下面这两个场景:
1. 用户服务在保存用户记录, 还没来得及向消息队列发送消息之前就宕机了. 怎么保证用户创建事件一定发送到消息队列了?
2. 代金券服务接收到用户创建事件, 还没来得及处理事件就宕机了. 重新启动之后如何消费之前的用户创建事件?
这两个问题的本质是: 如何让操作数据库和操作消息队列这两个操作成为一个原子操作. 不考虑2PC, 这里我们可以通过事件表来解决这个问题. 下面是类图. 
EventPublish是记录待发布事件的表. 其中:
id: 每个事件在创建的时候都会生成一个全局唯一ID, 例如UUID.
status: 事件状态, 枚举类型. 现在只有两个状态: 待发布(NEW), 已发布(PUBLISHED).
payload: 事件内容. 这里我们会将事件内容转成json存到这个字段里.
eventType: 事件类型, 枚举类型. 每个事件都会有一个类型, 比如我们之前提到的创建用户USER_CREATED就是一个事件类型.
EventProcess是用来记录待处理的事件. 字段与EventPublish基本相同.
我们首先看看事件的发布过程. 下面是用户服务发布用户创建事件的顺序图. 
1. 用户服务在接收到用户请求后开启事务, 在用户表创建一条用户记录, 并且在EventPublish表创建一条status为NEW的记录, payload记录的是事件内容, 提交事务.
2. 用户服务中的定时器首先开启事务, 然后查询EventPublish是否有status为NEW的记录, 查询到记录之后, 拿到payload信息, 将消息发布到kafka中对应的topic.
发送成功之后, 修改数据库中EventPublish的status为PUBLISHED, 提交事务.
下面是代金券服务处理用户创建事件的顺序图. 
1. 代金券服务接收到kafka传来的用户创建事件(实际上是代金券服务主动拉取的消息, 先忽略消息队列的实现), 在EventProcess表创建一条status为NEW的记录, payload记录的是事件内容, 如果保存成功, 向kafka返回接收成功的消息.
2. 代金券服务中的定时器首先开启事务, 然后查询EventProcess是否有status为NEW的记录, 查询到记录之后, 拿到payload信息, 交给事件回调处理器处理, 这里是直接创建代金券记录. 处理成功之后修改数据库中EventProcess的status为PROCESSED, 最后提交事务.
回过头来看我们之前提出的两个问题:
1. 用户服务在保存用户记录, 还没来得及向消息队列发送消息之前就宕机了. 怎么保证用户创建事件一定发送到消息队列了?
根据事件发布的顺序图, 我们把创建事件和发布事件分成了两步操作. 如果事件创建成功, 但是在发布的时候宕机了. 启动之后定时器会重新对之前没有发布成功的事件进行发布. 如果事件在创建的时候就宕机了, 因为事件创建和业务操作在一个数据库事务里, 所以对应的业务操作也失败了, 数据库状态的一致性得到了保证.
2. 代金券服务接收到用户创建事件, 还没来得及处理事件就宕机了. 重新启动之后如何消费之前的用户创建事件?
根据事件处理的顺序图, 我们把接收事件和处理事件分成了两步操作. 如果事件接收成功, 但是在处理的时候宕机了. 启动之后定时器会重新对之前没有处理成功的事件进行处理. 如果事件在接收的时候就宕机了, kafka会重新将事件发送给对应服务.
通过这种方式, 我们不用2PC, 也保证了多个数据源之间状态的最终一致性.
和2PC/3PC这种同步事务处理的方式相比, 这种异步事务处理方式具有异步系统通常都有的优点:
1. 事务吞吐量大. 因为不需要等待其他数据源响应.
2. 容错性好. A服务在发布事件的时候, B服务甚至可以不在线.
缺点:
1. 编程与调试较复杂.
2. 容易出现较多的中间状态. 比如上面的例子, 在用户服务已经保存了用户并发布了事件, 但是代金券服务还没来得及处理之前, 用户如果登录系统, 会发现自己是没有代金券的. 这种情况可能在有些业务中是能够容忍的, 但是有些业务却不行. 所以开发之前要考虑好.
另外, 上面的流程在实现的过程中还有一些可以改进的地方:
1. 定时器在更新EventPublish状态为PUBLISHED的时候, 可以一次批量更新多个EventProcess的状态.
2. 定时器查询EventProcess并交给事件回调处理器处理的时候, 可以使用线程池异步处理, 加快EventProcess处理周期.
3. 在保存EventPublish和EventProcess的时候同时保存到Redis, 之后的操作可以对Redis中的数据进行, 但是要小心处理缓存和数据库可能状态不一致问题.
4. 针对Kafka, 因为Kafka的特点是可能重发消息, 所以在接收事件并且保存到EventProcess的时候可能报主键冲突的错误(因为重复消息id是相同的), 这个时候可以直接丢弃该消息.