TX-LCN分布式事务管理
# 一、分布式事务
# 1. 分布式事务是什么？
在分布式系统中，事务参与者在不同的分布式节点上或事务操作的数据源不是同一个，这些情况产生的事务都叫做分布式事务。
例如：
项目A实现Tb_item表新增、项目B实现tb_item_param新增，现在需要实现商品新增，需要把项目A和项目B两个项目新增的方法组成一个事务，这个事务就是分布式事务。
例如：
项目中向MySQL做新增，同时还需要向Redis或MongoDB执行新增，希望执行MySQL或Redis或MongoDB时如果出现异常进行事务回滚，这种情况也成为分布式事务。
# 2. 什么时候使用分布式事务
事务的概念最早是在学习数据库（MySQL、Oracle）中接触到的，一个事务（本地事务）就是一系列SQL语句的集合，只要在执行过程中一条SQL出错就会导致整个事务失败，回滚到原点。而在分布式系统中存在多模块完成一次业务。那么就存在一个业务由多模块操作同一个数据源。
甚至可能存在一个业务横跨多种数据源节点的可能。这些问题都可以由分布式事务解决方案TX-LCN解决。
# 3、分布式事务常见解决方案
# 3.1 基于XA协议的两阶段提交
分布式事务通常采用2PC协议，全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下，所有节点间数据一致性的问题。分布式事务通过2PC协议将提交分成两个阶段：
- prepare
- commit/rollback
阶段一为准备（prepare）阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。
阶段二为提交阶段（commit）。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
# 3.2 消息事务+最终一致性
所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功并且对外发消息成功，要么两者都失败
分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各 种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数 据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。
# 二、分布式事务理论依据
分布式事务存在两大理论依据：CAP定理和BASE理论。
1. CAP定理
CAP定理是指在一个分布式系统中Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性)，最多同时满足其中两个，三者不可兼得。
1.1 一致性（C）
在分布式系统中所有节点的状态是一样的。
1.2 可用性（A）
在集群中一部分节点出现故障后，整个集群是否还能响应客户端请求。
1.3 分区容错性（P）
以实际效果而言，分区相当于对操作的时限要求。如果系统不能在一定时限内达到数据一致性，就意味着发生了分区的情况，此时就必须在A和C中做选择。
2. BASE理论
是指Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。
BASE理论是对CAP中一致性和可用性权衡的结果，是基于CAP演化而来的。
BASE理论核心思想：即使无法做到强一致性，每个应用都可以根据自身业务特点，采用适当的方式达到最终一致性。
2.1 基本可用（BA）
是指在分布式系统中出现不可知故障的时候，允许损失部分可用性。此处要注意：损失部分可用性，不代表整个系统不可用。
例如：
- \1) 可以增加响应时间。由之前0.5秒，在出现故障的时候变成1~2秒。
- \2) 由于一些特殊原因，使网站访问流量激增，为了保证整个系统的稳定性，部分访问者可能被引导到降级页面中。
2.2 软状态（S）
是指系统中数据允许存在中间状态（软状态），并认为这个状态是不影响系统的可用性的。通俗解释：允许分布式节点之间存在同步延迟。
例如：
在Eureka集群中数据同步时就存在软状态。
2.3 最终一致性
允许整个系统中数据在经过一定时间后，最终能达到整个系统的一致性。但是这个时间绝对不可以过长。
强一致性要求系统接收请求后，整个系统必须达到一致性效果，才会响应结果。
最终一致性是弱一致性的特例。满足最终一致性的系统在响应给用户结果时整个系统可能是没有达到一致性的，但是最终一定会达到一致性效果的。
# 三、TX-LCN概述
1. 简介
LCN框架在2017年6月发布第一个版本，目前最新已经达到5.0版本。
LCN早期设计时，1.0版本和2.0版本设计步骤如下：
- 1）锁定事务单元（Lock）
- 2）确认事务模块状态（Confirm）
- 3）通知事务（Notify）
取各自首字母后名称为LCN。
LCN框架从5.0开始兼容了LCN、TCC、TXC三种事务模式，为了和LCN框架区分，从5.0开始把LCN框架更名为：TX-LCN分布式事务框架。
2. TX-LCN原理
TX-LCN由两大模块组成，TxClient、TxManager。
TxClient作为模块的依赖框架，提供了TX-LCN的标准支持，事务发起方和参与方都属于TxClient。TxManager作为分布式事务的控制方，控制整个事务。
2.1 原理中核心内容
1） 创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标识GroupId的过程。
2） 加入事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。
3） 通知事务组
是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。
# 四、TX-LCN事务模式
Tx-LCN 5.0开始支持三种事务模式，分别是：LCN、TCC、TXC模式。
每种模式在实际使用时有着自己对应的注解。
LCN：@LcnTransaction
TCC：@TccTransaction
TXC：@TxcTransaction
1. LCN模式
1.1 原理介绍
LCN模式是通过代理JDBC中Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。
1.2 模式特点
- 该模式对代码的嵌入性低。
- 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。
- 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。
- 该模式缺陷在于代理的连接需要随事务发起方一同释放连接，增加了连接占用的时间。
总结：LCN模式适合能用JDBC连接的所有支持事务的数据库
2. TCC事务模式
2.1 原理介绍
TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。
2.2 代码说明
每个TCC事务处理方法可以额外包含confirmXxx和cancelXxx的方法（），出现失败问题，需要在cancel中通过业务逻辑把改变的数据还原回来。
confirmXxx和cancelXxx 两个方法会由TxManager进行统一协调调用。
confirmXxx和cancelXxx也可以在@TccTransaction注解中通过属性明确指定。
# LCN介绍
TX-LCN分布式事务框架，LCN并不生产事务，LCN只是本地事务的协调工，LCN是一个高性能的分布式事务框架，兼容dubbo、springcloud框架，支持RPC框架拓展，支持各种ORM框架、NoSQL、负载均衡、事务补偿
特性一览
1、一致性，通过TxManager协调控制与事务补偿机制确保数据一致性
2、易用性，仅需要在业务方法上添加@TxTransaction注解即可
3、高可用，项目模块不仅可高可用部署，事务协调器也可集群化部署
4、扩展性，支持各种RPC框架扩展，支持通讯协议与事务模式扩展
参考文章和视频