分布式事务

分布式事物的问题

一个业务流程中要跨多个服务调用(写操作),就会存在分布式事物问题

针对一些特定的场景、核心的流程 数据的准确性和可靠性尤其的重要如:订单、支付、入账 etc.

分布式事物的业务代码场景

/** 支付订单处理 **/ @Transactional(rollbackFor = Exception.class) public void completeOrder(){ orderDao.update(); // 订单服务本地更新订单状态 accountService.update(); // 调用资金账户服务给资金帐户加款 pointService.update(); // 调用积分服务给积分帐户增加积分 accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证 merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知 }

问题: 本地事物控制是否可行？有一个远程服务失败?是否可以回滚? 常见的分布式处理方案 刚性事物

1.全局事物 柔性事物

1.基于MQ的最终一致性方案

2.TCC 事物补偿性方案

3.最大努力通知型方案

事物

本地事物

1.在单个数据库的本地并且限制在单个进程内的事物

2.本地事物不涉及多个数据来源

全局事务 DTP模型

标准分布式事务

AP (Application Program) : 也就是应用程序，可以理解为使用DTP 的程序

RM (Resource Manager) : 资源管理器 (这里是一个 DBMS，或者消息服务管理系统，应用程序通过资源管理器对资源进行控制，资源必须实现XA定义的接口。

TM (Transaction Manager) : 事物管理器，负责协调和管理事物，也提供给AP 应用程序编程接口以及管理 资源管理器。

事物管理器控制着全局事物，管理事物生命周期，并协调资源。资源管理器负责控制和管理实际资源。

XA

XA是由X/Open 组织提出的分布式事务的规范。XA规范主要定义了全局事物管理器™和局部资源管理器(RM) 之间的接口。主流的关系型数据库产品都实现了XA接口。

XA接口是双系统接口，在事务管理器（TM）以及一个或多个资源管理器(RM) 之间形成通信桥梁。

XA之所所以需要引入事务管理器是因为，在分布式系统中，从理论上讲两台机器理论上无法达到一致的状态，需要引入一个单点进行协调

由全局事务管理器管理和协调的事务，可以跨多个资源(如数据库活JMS队列)和进程。全局事务管理器一般使用XA 二阶段提交协议与数据库进行交互。

两阶段提交(Two Phase Commit)

两阶段提交协议（Two-phase commit protocol）是XA用于在全局事务中协调多个资源的机制。 TM和RM间采取两阶段提交(Two Phase Commit) 的方案来解决一致性问题 两阶段提交需要一个协调者（TM）来掌控所有参与者节点（RM）的操作结果并且指引这些节点是否需要最终提交。

JavaEE平台中的分布式事务实现

JTA(Java Transaction API)：面向应用、应用服务器与资源管理器的高层事务接口。 JTS(Java Transaction Service)：JTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性。 EJB：基于组件的应用编程模型，通过声明式事务管理进一步简化事务应用的编程。

优点 简单一致的编程模型 跨域分布处理的ACID保证

局限 DTP模型本身的局限

标准分布式事务解决方案的利弊

优点：严格的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定理:

指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时）

可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）

分区容错性（P）：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

C A 满足的情况下，P不能满足的原因：

数据同步©需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足

CP 满足的情况下，A不能满足的原因： 数据同步©需要时间, 机器数量也多§，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足

AP 满足的情况下，C不能满足的原因： 机器数量也多§，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足

常见的注册中心:

Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足

Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

结论：

分布式系统中P,肯定要满足，所以只能在CA中二选一

没有最好的选择，最好的选择是根据业务场景来进行架构设计

分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性

柔性事物

柔性事务的分类：

两阶段型

异步确保型

最大努力通知型

柔性事务中的服务模式

可查询操作

一、服务操作的可标识性 服务操作具有全局唯一标识 可以使用业务单据号（如订单号） 或者使用系统分配的操作流水号（如支付记录流水号） 或者使用操作资源的组合组合标识（如商户号+商户订单号） 操作有唯一的、确定的时间(约定以谁的时间为准)

二、单笔查询 使用全局唯一的服务操作标识，查询操作执行结果 注意状态判断，小心“处理中” 的状态 三、批量查询 使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果

幂等操作

幂等性 (Idempotenty) f(f(x)) = f(x)

幂等操作 重复调用多次产生的业务结果与调用一次产生的业务结果相同

实现方式一 通过业务操作本身实现幂等性

实现方式二 系统缓存所有请求与处理结果 检测到重复请求之后，自动返回之前的处理结果

TCC操作

Try: 尝试执行业务 完成所有业务检查(一致性) 预留必须业务资源(准隔离性)

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

Cancel: 取消执行业务 释放Try阶段预留的业务资源 Cancel操作要满足幂等性

与2PC协议比较 位于业务服务层而非资源层 没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的，锁定粒度(以业务定粒度) 较高开发成本

误区：很多人把两阶段型操作等同于两阶段提交协议2PC操作。其实TCC操作属于两阶段型操作。

可补偿操作

do: 真正执行业务

完成业务处理 业务执行结果外部可见

compensate:业务补偿 抵销(或部分抵销)正向业务操作的业务结果 补偿操作满足幂等性

约束 补偿在业务上可行 由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控

（TCC操作中的Confirm操作和Cancel操作，其实也可以看作是补偿操作）

可靠消息最终一致（异步确保型）

实现

业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送

消息 业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效

约束 被动方的处理结果不影响主动方的处理结果， 被动方的消息处理操作是幂等操作

成本 可靠消息系统建设成本 一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口

优点、适用范围 消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合

对最终一致性时间敏感度较高，降低业务被动方实现成本

用到的服务模式 可查询操作、幂等操作

特点 给予JMS标准的来实现,符合JMS MQ 均可以满足 确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）

行业应用案例 支付宝、eBay（BASE）、去哪儿、京东

TCC（两阶段型、补偿型）

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

成本 实现TCC操作的成本 业务活动结束时confirm或cancel操作的执行成本 业务活动日志成本

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

三方框架

https://github.com/changmingxie/tcc-transaction.git

用到的服务模式 TCC操作、幂等操作、可补偿操作、可查询操作

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

行业应用案例 支付宝XTS（蚂蚁金融云的分布式事务服务DTS）