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

事务是由一组操作构成的可靠，独立的工作单元。

ACID：

Atomicity(原子性）

Consistency（一致性）

isolation（隔离性）

durability（持久性）

难点：

高度并发

资源分布

大时间跨度

本地事务：

事务由资源管理器（如DBMS）本地管理

优点：

支持严格的acid属性

可靠

高效

状态可以只在资源管理器中维护

应用编程模型简单（在框架或平台的支持）

局限

不具备分布式事务处理能力

隔离的最小单位由资源管理器决定，如数据库中的一条记录

在传统解决分布式事务也有些解决方案，比如全局事务（dtp模型）--标准分布式事务

全局事务-->事务由全局事务管理器全局管理

事务管理器-->管理全局事务状态与参与的资源，协同资源的一致性提交/回滚

tx协议-->应用或应用服务器与事务管理的接口

xa协议-->全局事务管理器与资源管理器的接口

Ap（application program）：也就是应用程序，可以理解为使用dtp的程序

rm（resource manager）：资源管理器（这里可以是一个dbms，或者消息服务器管理系统）应用程序通过资源管理器对资源进行控制，资源必须实现xa定义的接口。

tm（transaction manager）：事务管理器，负责协调和管理事务，提供给ap应用程序编程接口以及管理资源管理器。

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

xa是由x/open组织提出的分布式事务的规范。xa规范主要定义了（全局）事务管理器（tm）和（局部）资源管理器（rm）之间的接口，主流的关系型数据库产品都是实现xa接口的。

xa接口是双向的系统接口，在事务管理器（tm）以及一个或多个资源管理器（rm）之间形成通信桥梁。

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

由全局事务管理器管理或协调的事务，可以跨越多个资源（如数据库或jms队列）和进程。全局事务管理器一般都用xa二阶段提交协议与数据库进行交互。

两阶段提交（two phase commit）两阶段提交协议（two-phase commit protocol）是xa用于在全局事务中协调多个资源的机制。

tm和rm间采用两阶段提交（two phase commit）的方案来解决一致性问题

两阶段提交需要一个协调者（tm）来掌控所有参与者节点（rm）的操作结果并且指引这些节点是否需要最终提交

准备操作与acid：

a，准备后，仍可提交与回滚

c，准备时，一致性检查必须ok

i：准备后，事务结果任然只在事务内可见

d：准备后，事务结果已经持久。

局限：

协议成本

准备阶段的持久成本

全局事务状态的持久成本

潜在故障点多带来的脆弱性

准备后，提交前的故障引发一系列隔离与恢复难题。

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）与隔离性（l）的要求

酸碱平衡（ACID-BASE BALANCE）

cap定理：

定理：对于共享数据系统，最多只能同时拥有cap其中的两个，没法三者兼顾

任两者的组合都有其适用场景

真实系统应当是acid与base的混合体

不同类型的业务可以也应当区别对待

其中一致性是指所有用户看到一致的数据

可用性是指总能找到一个可用数据复本

分区容错性是指可以容忍网络中断

结论：分布式系统中，最重要的是满足业务需求，二不是追求抽象，绝对的系统特性。