分布式事务实现方式--LCN

什么是分布式事务,分布式事务的出现解决了什么?

分布式事务产生的原因:
从本地事务来看，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。
service多个节点:
随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护, 这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

resource多个节点:
同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功

分布式事务CAP与BASE理论:

CAP

CAP定理，又被叫作布鲁尔定理。对于设计分布式系统来说(不仅仅是分布式事务)的架构师来说，CAP就是你的入门理论。

• C
  (一致性):对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。

• A
  (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。

• P
  (分区容错性):当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

  熟悉CAP的人都知道，三者不能共有，如果感兴趣可以搜索CAP的证明，在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
  对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。
  对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。

BASE
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展

• 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
  软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
  最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
分布式解决方案–TX-LCN分布式事务管理
一,LCN介绍:
LCN 名称是由早期版本的 LCN 框架命名，在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名。
*****锁定事务单元（lock）
*****确认事务模块状态(confirm)
*****通知事务(notify)
“LCN并不生产事务，LCN只是本地事务的协调者”,LCN分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强，支持所有的关系型数据库事务，支持多数据源，支持与第三方数据库框架一块使用（例如 sharding-jdbc），在使用框架的时候只需要添加分布式事务的注解即可，对业务的侵入性低。
LCN框架主要是为微服务框架提供分布式事务的支持，在微服务框架上做了进一步的事务机制优化，在一些负载场景上LCN事务机制要比本地事务机制的性能更好，4.0以后框架开方了插件机制可以让更多的第三方框架支持进来。
LCN 5.0 以后由于框架兼容了 LCN、TCC、TXC 三种事务模式，为了避免区分 LCN 模式，特此将 LCN 分布式事务改名为 TX-LCN 分布式事务框架。
TX-LCN 定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。LCN 并不生产事务，LCN 只是本地事务的协调工。
TX-LCN 支持跨 Web 服务器，微服务之间的 Feign 远程调用，支持集群、熔断。

二,LCN框架特点:

1. 支持各种基于spring的db框架
2. 兼容SpringCloud、Dubbo、motan
3. 使用简单，低依赖，代码完全开源
4. 基于切面的强一致性事务框架
5. 高可用，模块可以依赖RPC模块做集群化，TxManager也可以做集群化
6. 支持本地事务和分布式事务共存
7. 支持事务补偿机制，增加事务补偿决策提醒
8. 添加插件拓展机制
   目录介绍
   

三,LCN原理
1,架构介绍

如上图可知, lcn是通过nginx作为负载均衡的转发，也就是作为Txmanager的负载均衡的一个转发服务器；然后再是我们的TxManager,也就是事务管理器，然后事务管理器依赖两个服务，一个是redis服务，一个是Eureka服务集群；Eureka集群是用于我们TxManager之间的相互服务发现。redis是用于存放我们事务组的信息以及补偿的信息。然后模块A与模块B他们都需要去配置上我们TxClient的包架构（代码的包架构）；来支持我们的LCN框架,以及他们的数据库。
2,LCN核心三步骤

如图，在一次事务中发起的就叫做启动者或者是发起方。然后其他的微服务框架都叫做事务的参与者。
事务组是指的我们在整个事务过程中把各个节点（微服务）单元的事务信息存储在一个固定单元里。但这个信息并不是代表是事务信息，而是只是作为一个模块的标示信息。

创建事务组
是指在事务发起方代码开始执行业务之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。（这里的groupId表示的是一次事务的唯一标示，就是指我们一次事务中，会有一个groupId存在。其次这里讲述在开始执行业务之前，是因为框架是基于切面的思想，那么切面就切面到了这个方法的业务执行过程中，然后又一个around切面。再然后在开始之前，在业务没有调用业务之前会先调用TxManager去创建事务组，然后创建完事务组以后Txmanager会返回事务组信息，事务组信息中就包含GroupId这个参数，这也就是作为的创建事务组。创建完事务组之后就相当于已经产生一个事务组标示。作为一个串联过程，识别为同一次事务的一个过程）
添加事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息添加通知给TxManager的操作。
关闭事务组
是指在发起方执行完业务代码以后（执行到这个地方就表明没有错误和异常，也就是执行结束了，否则并不会执行到这个地方），将发起方执行结果状态通知给TxManager的动作。当执行完关闭事务组的方法以后，TxManager将根据事务组信息来通知相应的参与模块提交或回滚事务。

3、事务协调机制

LCN事务控制原理是由事务模块TxClient下的代理连接池与TxManager的协调配合完成的事务协调控制。
TxClient的代理连接池实现了javax.sql.DataSource接口，并重写了close方法，事务模块在提交关闭以后TxClient连接池将执行"假关闭"操作，等待TxManager协调完成事务以后在关闭连接。

对于代理连接池的优化
自动超时机制
任何通讯都有最大超时限制，参与模块在等待通知的状态下也有最大超时限制，当超过时间限制以后事务模块将先确认事务状态，然后再决定执行提交或者回滚操作，主要为了给最大资源占用时间加上限制。

智能识别创建不同的连接 对于只读操作、非事务操作LCN将不开启代理功能，返回本地连接对象，对于补偿事务的启动方将开启回滚连接对象，执行完业务以后马上回滚事务。

LCN连接重用机制 当模块在同一次事务下被重复执行时，连接资源会被重用，提高连接的使用率。

4.事务补偿机制
事务补偿是指在执行某个业务方法时，本应该执行成功的操作却因为服务器挂机或者网络抖动等问题导致事务没有正常提交，此种场景就需要通过补偿来完成事务，从而达到事务的一致性。

补偿机制的触发条件？

当执行关闭事务组步骤时，若发起方接受到失败的状态后将会把该次事务识别为待补偿事务，然后发起方将该次事务数据异步通知给 TxManager。
TxManager 接受到补偿事务以后先通知补偿回调地址，然后再根据是否开启自动补偿事务状态来补偿或保存该次切面事务数据。

补偿事务机制？
LCN的补偿事务原理是模拟上次失败事务的请求，然后传递给TxClient模块然后再次执行该次请求事务。
简单的说：lcn事务补偿是在在服务挂机和网络抖动情况下；服务挂机是指在完成三个核心步骤的时候
尤其也只有最后一步关闭事务组时，让我去执行关闭事务组的时候，比如本次事务是要提交的。txManager接收到提交的请求再去通知的时候发现通知不到了。（通知不到也就两种原因服务挂了和网络出问题）在这种情况下TxManager会做一个标示;然后返回给发起方。告诉他本次事务有存在没有通知到的情况。
那么如果是接收到这个信息之后呢，发起方就会做一个标示，标示本次事务是需要补偿事务的。这就是事务补偿机制。

总结
LCN框架将可以确保在⾮极端场景下（TM宕机、TC宕机、⽹络异常、数据库宕机）的事务幂等性与强⼀致性，理论上其性能相⽐本地事务要稍显逊⾊，但是相⽐逆向SQL⽅式及不可控代理模式来说更有优势。LCN框架也可⽀持对多数据源的适配、对各种DB框架、各种数据库的兼容适配，且⽆需要针对各种数据库做适配程序，也可⽀持存储过程的执⾏，⽽且可包容TCC[8]、TXC等其他模式的兼容。
LCN使用说明:
分布式事务发起方：

分布式事务调用方: