分布式事务方案

全局事务（DTP模型）

全局事务：事务由全局事务管理器全局管理 。
事务管理器：管理全局事务状态与参与的资源，协同资源的一致性提交/回滚。
TX协议：应用或应用服务器与事务管理器的接口。
XA协议：全局事务管理器与资源管理器的接口。

XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了（全局）事务管理器（TM）和（局部）资源管理器（RM）之间的接口。主流的关系型数据库产品都市实现了XA接口的。
XA接口是双向的系统接口，在事务管理器（TM）以及一个或多个资源管理器（RM）之间形成通信桥梁。
XA之所以需要引入事务管理器是因为在分布式系统中，两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。
由全局事务管理器管理和协调的事务，可以跨越多个资源（如数据库或JMS队列）和进程。全局事务管理器一般使用XA二阶段提交协议与数据库进行交互。
两阶段提交协议是XA用于在全局事务中协调多个资源的机制。
TM和RM间采取两阶段提交的方案来解决一致性问题。
两阶段提交需要一个协调者（TM）来掌握所有参与者节点（RM）的操作结果并且指引这些节点是否需要最终提交。

JTA：面向应用、应用服务器与资源管理器的高层事务接口。
标准分布式事务解决方案的利弊：
优点：严格的ACID。
缺点：效率非常低（微服务架构下不太适合）

• 全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（2PC）与资源层（如数据库）进行交互。使用全局事务，数据被Lock的时间跨整个事务。直到全局事务结束。
• 2PC是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模越来越大的情况下，2PC的局限性就越来越明显，系统可伸缩会变得很差。
• 与本地事务相比，XA协议的系统开销相当大，因而应当慎重考虑是否需要分布式事务。而且只有支持XA协议的资源才能参与分布式事务。

BASE理论

• BASE
  
  • BA：Basic Availability 基本业务可用性（支持分区失败）
  • S：Soft state 柔性状态（状态允许有短时间不同步，异步）
  • E：Eventual consistency 最终一致性（最终数据是一致，但不是实时一致）
• 原子性（A）与持久性（D）必须根本保障
• 为了可用性、性能与降级服务的需要，只有降低一致性（C）与隔离性（I）的要求
• 酸碱平衡（ACID-BASE Balance）

CAP定理

• 定理：对于共享数据系统，最多只能同时拥有CAP其中的两个，没法三者兼顾。
• 任两者的组合都有其适用场景
• 真实系统应当是ACID与BASE的混合体
• 不同类型的业务可以也应当区别对待

柔性事务

柔性事务中的服务模式

• 可查询操作
• 幂等操作
• TCC操作
• 可补偿操作

服务模式是柔性事务流程中的特殊操作实现（实现上对应业务服务要提供的模式的功能接口），还不算是某一种柔性事务解决方案。

1. 可查询操作

   • 服务操作的可标识性
     
     • 服务操作具有全局标识
       
       • 可以使用业务单据号（如订单号）
       • 或者使用系统分配的操作流水号（如支付记录流水号）
       • 或者使用操作资源的组合标识（如商户号+商户订单号）
     • 操作有唯一的、确定的时间（约定以谁的时间为准）
   • 单笔查询
     
     • 使用全局唯一的服务操作标识，查询操作执行结果
     • 注意状态判断，小心“处理中”的状态
   • 批量查询
     
     • 使用时间区段与（或）一组服务操作的标识，查询一批操作执行结果

2. 幂等操作

   • 幂等性 f(f(x)) = f(x)
   • 幂等操作，重复调用多次产生的业务结果与调用一次产生的业务结果相同
   • 实现方式一，通过业务操作本身实现幂等性
   • 实现方式二
     
     • 系统缓存所有请求与处理结果
     • 检测到重复请求之后，自动返回之前的处理结果

3. TCC操作

   • Try：尝试执行业务
     
     • 完成所有业务检查（一致性）
     • 预留必须业务资源（准隔离性）
   • Confirm：确认执行业务
     
     • 真正执行业务
     • 不做任务业务检查
     • 只使用业务检查
     • 只使用Try阶段预留的业务资源
     • Confirm操作要满足幂等性
   • Cancel：取消执行业务
     
     • 释放Try阶段预留的业务资源
     • Cancel操作要满足幂等性
   • 与 2PC协议比较
     
     • 位于业务服务层而非资源层
     • 没有单独的准备阶段，Try操作兼备资源操作与准备能力
     • Try操作可以灵活选择业务资源的锁定粒度（以业务粒度）
       -较高开发成本

4. 可补偿操作

   • do：真正执行业务
     
     • 完成业务处理
     • 业务执行结果外部可见
   • compensate：业务补偿
     
     • 抵消（或部分抵消）正向业务操作的业务结果
     • 补偿操作满足幂等性
   • 约束
     
     • 补偿在业务上可行
     • 由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控

常用的分布式事务解决方案

• 刚性事务
  
  • 全局事务（标准的分布式事务）
• 柔性事务
  
  • 可靠消息最终一致
  • TCC（两阶段、补偿型）
  • 最大努力通知（非可靠消息、定期校对）
  • 纯补偿型

消息中间件

消息中间件在分布式系统中的主要作用：异步通信、解耦、并发缓冲。
消息发送和投递的不可靠性，分布式部署环境下，需要通过网络进行通信，就引入了数据传输的不确定性，也就是CAP理论中的P（分区容错性的问题）。
消息发送一致性：是指产生消息的业务动作与消息发送的一致。就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息。

• JMS协议标准的API中，有很多以XA开头的接口，其实就是XA协议的全局事务型接口。
• JMS中的XA系列接口，可以提供分布式事务支持。
• 但应用了XA方式的分布式事务，又带来了局限性：
  
  • 要求业务操作的资源必须支持XA协议（并不是所有资源都支持XA）
  • 两阶段提交协议的成本
  • 持久化成本等DTP模型的局限性（全局锁定，成本高，性能低）

MQ队列消息模型的特点：
1. 消息生产者将消息发送到Queue中，然后消息消费者监听Queue并接收消息。
2. 消息被确认消费以后，就会从Queue中删除，所以消息消费者不会消费到已被消费的的信息。
3. Queue支持存在多个消费者，但是对某个消息而言，只会有一个消费者成功消费。

消息重复发送主要是因为消息接收者成功处理完消息后，消息中间件没能及时更新消息投递状态（消息没能及时ACK确认）。

业务接口的幂等性设计
- 对于存在同一请求数据会发生重复调用的业务接口，接口的业务逻辑要实现幂等设计。
- 在实际的业务应用场景中，业务接口的幂等性设计，常结合可查询操作一起使用。

消息重复发送限制，对于超过重发次限制的消息，进入DLQ，等待人工干预或延后定期处理。

基于可靠消息的最终一致性方案

异步确保型，适用场景比较广。

• 实现
  
  • 业务处理服务在业务事务提交前，向实时消息服务器请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送。
• 消息
  
  • 业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问的消息状态，业务处理服务根据ID或消息内容确定该消息是否有效
• 约束
  
  • 被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作
• 成本
  
  • 可靠消息系统建设成本
  • 一次消息发送两次请求，业务处理服务需要实现消息状态回查接口

• 优点、适用范围

  • 消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合
  • 对最终一致性时间敏感较高，降低业务被动方实现成本

• 用到的服务模式

  • 可查询操作、幂等操作
• 方案特点
  
  • 兼容所有实现JMS标准的MQ中间件
  • 确保业务数据可靠的前提下，实现业务数据的最终一致

方案一：本地消息服务
优点：
1. 消息时效性高
2. 从应用设计开发的角度时效了消息数据的可靠性，消息数据的可靠性不依赖MQ中间件，弱化了对MQ中间件特性的依赖。
3. 方案轻量，容易实现。

局限：
1. 与具体的业务场景绑定，耦合性强，不可共用。
2. 消息数据与业务数据同库，占用业务系统资源。
3. 业务系统在使用关系型数据库的情况下，消息服务性能会受关系型数据库并发性能的局限。

方案二：独立的消息服务
优点：
1. 消息服务独立部署、独立维护、独立伸缩
2. 消息存储可以按需选择不同的数据库来集成实现。
3. 消息服务可以被相同的使用场景共用，降低重复建设消息服务的成本
4. 从应用（分布式服务）设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。
5. 降低了业务系统与消息系统间的耦合，有利于系统的开展维护。

局限：
1. 一次消息发送需要两次请求；
2. 主动方应用系统需要实现业务操作状态校验查询接口；

最大努力通知方案

• 实现
  
  • 业务活动的主动方，在 完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
  • 业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。
• 约束
  
  • 被动方的处理结果不影响主动方的处理结果
• 成本
  
  • 业务查询与校对系统的建设成本

• 使用范围

  • 对业务最终一致性的时间敏感度低
  • 跨企业的业务活动

• 用到的服务模式

  • 可查询操作
• 方案特点
  
  • 业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）
  • 主动方可以设置时间阶梯通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知
  • 主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的的业务消息
• 行业应用案例
  
  • 银行通知、商户通知（多次通知、查询校对、对账文件）

TCC事务补偿型方案

属于两阶段型的一种实现，区别于2PC协议的两阶段提交。

• 实现
  
  • 一个完整的业务活动由一个主业务服务与若干从业务服务组成
  • 主业务服务负责发起并完成整个业务活动
  • 从业务服务提供TCC型业务操作
  • 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作
• 成本
  
  • 实现TCC操作的成本
  • 业务活动结束时confirm或cancel操作的执行成本
  • 业务活动日志成本

• 适用范围

  • 强隔离性、严格一致性要求的业务活动
  • 适用于执行时间较短的业务（比如处理账户、收费等业务）

• 用到的服务模式

  • TCC操作、幂等操作、可补偿操作、可查询操作
• 方案特点
  
  • 不与具体的服务框架耦合（在RPC架构中通用）
  • 位于业务服务层，而非资源层
  • 可以灵活选择业务资源的锁定粒度
  • TCC对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）

TCC型分布式事务框架tcc-transaction，github地址：https://github.com/changmingxie/tcc-transaction,maven依赖：

<!-- tcc-transaction begin -->
<dependency>
    <groupId>org.mengyun</groupId>
    <artifactId>tcc-transaction-spring</artifactId>
    <version>${tcc.version}</version>
</dependency>
<dependency>
    <groupId>org.mengyun</groupId>
    <artifactId>tcc-transaction-core</artifactId>
    <version>${tcc.version}</version>
</dependency>
<dependency>
    <groupId>org.mengyun</groupId>
    <artifactId>tcc-transaction-api</artifactId>
    <version>${tcc.version}</version>
</dependency>
<!-- tcc-transaction end -->

• Try: 尝试执行业务

  • 完成所有业务检查（一致性）
  • 预留必须业务资源（准隔离性）

• Confirm: 确认执行业务

  • 真正执行业务
  • 不作任何业务检查
  • 只使用Try阶段预留的业务资源
  • Confirm操作满足幂等性

• Cancel: 取消执行业务

  • 释放Try阶段预留的业务资源
  • Cancel操作满足幂等性