SpringCloud(6) 分布式事务【概念、常见框架选择 - tx-lcn】

分布式事务简介：

事务: 指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行.
本地事务:  SqlSessionfactory   --》 一个数据库范围类事务管理.
分布式事务: 跨了多个数据库事务管理,在微服务架构每个服务都有自己数据库,在微服务架构中必然要用到分布式事务.

为什么需要分布式事务？

微服务应用相较于单体应用有以下不足:
①单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。
      随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用
②系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。
      对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。
③微服务数量众多，其测试、部署、监控等都变的更加困难。
      对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。

柔性事务 vs 刚性事务

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

CAP

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

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

BASE

跨数据库两段提交事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。
BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。
BASE思想的主要实现有
  1.按功能划分数据库
  2.sharding碎片

微服务事务方案

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.异步确保性：

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

执行步骤如下:

1. MQ发送方发送远程事务消息到MQ Server;
2. MQ Server给予响应, 表明事务消息已成功到达MQ Server.
3. MQ发送方Commit本地事务.
4. 若本地事务Commit成功, 则通知MQ Server允许对应事务消息被消费; 若本地事务失败, 则通知MQ Server对应事务消息应被丢弃.
5. 若MQ发送方超时未对MQ Server作出本地事务执行状态的反馈, 那么需要MQ Servfer向MQ发送方主动回查事务状态, 以决定事务消息是否能被消费.
6. 当得知本地事务执行成功时, MQ Server允许MQ订阅方消费本条事务消息.

需要额外说明的一点, 就是事务消息投递到MQ订阅方后, 并不一定能够成功执行. 需要MQ订阅方主动给予消费反馈(ack)

• 如果MQ订阅方执行远程事务成功, 则给予消费成功的ack, 那么MQ Server可以安全将事务消息移除;
• 如果执行失败, MQ Server需要对消息重新投递, 直至消费成功.

注意事项：
      消息中间件在系统中扮演一个重要的角色, 所有的事务消息都需要通过它来传达, 所以消息中间件也需要支持 HAC 来确保事务消息不丢失.
     根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复, 不乱序等其它要求.

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

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

优秀实践

1.如果业务场景需要强一致性, 那么尽量避免将它们放在不同服务中, 也就是尽量使用本地事务(ACID), 避免使用强一致性的分布式事务.

2.如果业务场景能够接受最终一致性, 那么最好是使用基于消息的最终一致性的方案(异步确保型)来解决.

3.如果业务场景需要强一致性, 并且只能够进行分布式服务部署, 那么最好是使用TCC方案而不是2PC方案来解决.

---

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

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比较NB但是不开源，所以选择tx-lcn

---

LCN分布式事务框架入门 可看我的另外一篇文章： https://blog.csdn.net/qq_38225558/article/details/86133637