分布式事务解决方案LCN

LCN

http://www.txlcn.org/zh-cn/index.html

分布式事务简介：

事务: 指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行.

本地事务:  SqlSessionfactory   --》 一个数据库范围类事务管理.

分布式事务:跨了多个数据库事务管理,在微 服 wu 架构每个服 wu 都有自己数据库,在微服 wu 架构中必然要用到分布式事务.

柔性事务 vs 刚性事务

刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务.
柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有:
     ①两阶段提交(2PC)
     ②TCC补偿型提交
     ③基于消息的异步确保型
     ④最大努力通知型

CAP

Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容忍性) 可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

1.基于XA协议的两阶段提交方案：

两阶段提交(Two Phase Commit, 2PC), 具有强一致性, 是CP系统的一种典型实现.常见的标准是XA, JTA等. 
  第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；
  第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚

缺点：
      两阶段提交中的第二阶段, 协调者需要等待所有参与者发出yes请求, 或者一个参与者发出no请求后, 才能执行提交或者中断操作. 这会造成长时间同时锁住多个资源, 造成性能瓶颈, 如果参与者有一个耗时长的操作, 性能损耗会更明显.
      实现复杂, 不利于系统的扩展, 不推荐.

2.TCC (Try-Confirm-Cancle)：

TCC, 是基于补偿型事务的AP系统的一种实现, 具有强一致性

      TCC能够对分布式事务中的各个资源进行分别锁定, 分别提交与释放, 例如, 假设有AB两个操作, 假设A操作耗时短, 那么A就能较快的完成自身的try-confirm-cancel流程, 释放资源. 无需等待B操作. 如果事后出现问题, 追加执行补偿性事务即可.
TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作), 也就是各服务之间可以在一定程度上”异步并行”执行.
缺点：
     对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
     实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等
注意：
    事务管理器(协调器)这个节点必须以带同步复制语义的高可用集群(HAC)方式部署.
事务管理器(协调器)还需要使用多数派算法来避免集群发生脑裂问题.
使用场景:
      严格一致性
      执行时间短
      实时性要求高
举例: 红包, 收付款业务.

3.异步确保性：

通过将一系列同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响. 最终一致性,中间有可能不一致

执行步骤如下:

MQ发送方发送远程事务消息到MQ Server;
MQ Server给予响应, 表明事务消息已成功到达MQ Server.
MQ发送方Commit本地事务.
若本地事务Commit成功, 则通知MQ Server允许对应事务消息被消费; 若本地事务失败, 则通知MQ Server对应事务消息应被丢弃.
若MQ发送方超时未对MQ Server作出本地事务执行状态的反馈, 那么需要MQ Servfer向MQ发送方主动回查事务状态, 以决定事务消息是否能被消费.
当得知本地事务执行成功时, MQ Server允许MQ订阅方消费本条事务消息.
需要额外说明的一点, 就是事务消息投递到MQ订阅方后, 并不一定能够成功执行. 需要MQ订阅方主动给予消费反馈(ack)

如果MQ订阅方执行远程事务成功, 则给予消费成功的ack, 那么MQ Server可以安全将事务消息移除;
如果执行失败, MQ Server需要对消息重新投递, 直至消费成功.
注意事项：
      消息中间件在系统中扮演一个重要的角色, 所有的事务消息都需要通过它来传达, 所以消息中间件也需要支持 HAC 来确保事务消息不丢失.
     根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复, 不乱序等其它要求.

执行周期较长、实时性要求不高

例如:
      1>跨行转账/汇款业务(两个服务分别在不同的银行中)
      2>退货/退款业务 
      3>财务, 账单统计业务(先发送到消息中间件, 然后进行批量记账)

分布式事务常见框架选择：

1.tcc-transaction

tcc-transaction是开源的TCC补偿性分布式事务框架，Git地址：https://github.com/changmingxie/tcc-transaction
TCC为Try、Confirm、Cancel的缩写：try阶段预留资源尝试提交，confirm阶段确定提交，cancel取消提交释放资源。
1.2.x项目指南地址：https://github.com/changmingxie/tcc-transaction/wiki/%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%971.2.x
侵入高

2.tx-lcn

介绍："LCN并不生产事务，LCN只是本地事务的协调者"
    LCN分布式事务框架的核心功能是对本地事务的协调控制，框架本身并不创建事务，只是对本地事务做协调控制。因此该框架与其他第三方的框架兼容性强，支持所有的关系型数据库事务，支持多数据源，支持与第三方数据库框架一块使用（例如 sharding-jdbc），在使用框架的时候只需要添加分布式事务的注解即可，对业务的侵入性低。LCN框架主要是为微服务框架提供分布式事务的支持，在微服务框架上做了进一步的事务机制优化，在一些负载场景上LCN事务机制要比本地事务机制的性能更好，4.0以后框架开方了插件机制可以让更多的第三方框架支持进来。
特点：
   ①支持各种基于spring的db框架
   ②兼容SpringCloud、Dubbo、motan
   ③使用简单，低依赖，代码完全开源
   ④基于切面的强一致性事务框架
   ⑤高可用，模块可以依赖RPC模块做集群化，TxManager也可以做集群化
   ⑥支持本地事务和分布式事务共存
   ⑦支持事务补偿机制，增加事务补偿决策提醒
   ⑧添加插件拓展机制

3.GTS–分布式事务解决方案

GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。
GTS的核心优势：
性能超强
GTS通过大量创新，解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。
应用侵入性极低
GTS对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。
完整解决方案
GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。  
有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。
容错能力强
GTS解决了XA事务协调器单点问题，实现真正的高可用，可以保证各种异常情况下的严格数据一致。
但是不开源！！

选择 GTS比较N但是不开源，所以选择tx-lcn

事务控制原理

    TX-LCN由两大模块组成, TxClient、TxManager，TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制放。事务发起方或者参与反都由TxClient端来控制。

原理图:

核心步骤

• 创建事务组
  是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

• 加入事务组
  添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。

• 通知事务组
  是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

 

 

    LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。

    TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

    TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据，然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库，目前锁实现依赖redis分布式锁控制。

 

事务模式说明：TCC是用户自己实现提交回滚业务，LCN是框架代理JDBC Connection实现提交回滚业务, TXC是框架分析业务SQL提前提交，在需要回滚时生成逆向回滚。

 

 

转载于:https://my.oschina.net/u/3151182/blog/3044584