spring cloud分布式事务 springcloud分布式事务有哪些_分布式事务

分布式事务简介：

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

为什么需要分布式事务？

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

柔性事务 vs 刚性事务

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

CAP

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

spring cloud分布式事务 springcloud分布式事务有哪些_微服务_02

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

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等.
  第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；
  第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚

spring cloud分布式事务 springcloud分布式事务有哪些_微服务_03

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

2.TCC (Try-Confirm-Cancle)：

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

spring cloud分布式事务 springcloud分布式事务有哪些_分布式事务_04

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

3.异步确保性：

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

spring cloud分布式事务 springcloud分布式事务有哪些_分布式事务_05

执行步骤如下:

  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