分布式事务

1、什么是分布式事务

分布式事务就是指事务的资源分别位于不同的分布式系统的不同节点之上的事务；

2、分布式事务产生的原因

2.1、数据库分库分表

在单库单表场景下，当业务数据量达到单库单表的极限时，就需要考虑分库分表，将之前的单库单表拆分成多库多表；

分库分表之后，原来在单个数据库上的事务操作，可能就变成跨多个数据库的操作，此时就需要使用分布式事务；

    在这种场景下，事务的提交会变得相对复杂，因为多个节点（库）的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个不同的数据库实例中保证。比如更新db1库的A表时，必须同步更新db2库的B表，两个更新形成一个事务，要么都成功，要么都失败。

2.2、业务服务化

业务服务化即业务按照面向服务（SOA）的架构拆分整个网站系统；

比如互联网金融网站SOA拆分，分离出交易系统、账务系统、清算系统等，交易系统负责交易管理和记录交易明细，账务系统负责维护用户余额，所有的业务操作都以服务的方式对外发布；

一笔金融交易操作需要同时记录交易明细和完成用户余额的转账，此时需要分别调用交易系统的交易明细服务和账务系统的用户余额服务，这种跨应用、跨服务的操作需要使用分布式事务才能保证金融数据的一致性；

 

3、分布式事务原理简介

   资源管理器（resource manager）：用来管理系统资源，是通向事务资源的途径。数据库就是一种资源管理器。资源管理还应该具有管理事务提交或回滚的能力。
   事务管理器（transaction manager）：事务管理器是分布式事务的核心管理者。事务管理器与每个资源管理器（resource 
manager）进行通信，协调并完成事务的处理。事务的各个分支由唯一命名进行标识。
   mysql在执行分布式事务（外部XA）的时候，mysql服务器相当于xa事务的资源管理器，与mysql链接的客户端相当于事务管理器。

3.1、ACID

1、原子性（Atomicity）

整个事务中的所有操作，要么都成功，要么都失败，不可能部分操作成功部分操作失败；

2、一致性（Consistency）

事务必须使数据库的数据从一个一致性状态变换到另外一个一致性状态。

3、隔离性（Isolation）

事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

4、持久性（Durability）

在事务成功以后，该事务对数据库所做的更改应当持久的保存在数据库中；

3.2、2PC

两阶段提交协议（Two Phase Commitment Protocol）是分布式事务的基础协议。

在此协议中，一个事务协调器（TM, transaction manager）协调多个资源管理器（RM, resource manager）的活动；在一阶段所有资源管理器（RM）向事务管理器（TM）汇报自身活动状态，在第二阶段事务管理器（TM）根据各资源管理器（RM）汇报的状态，来决定各RM是执行提交操作还是回滚操作；具体描述如下：

prepare;

commit/rollback;

1) 应用程序向事务管理器（TM）提交请求，发起方分布式事务；

2) 一阶段，事务管理器（TM）联络所有资源管理器（RM），通知它们执行准备操作；即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。

3) 资源管理器（RM）返回准备成功，或者失败的消息给TM（响应超时算作失败）；

4) 二阶段，如果所有RM均准备成功，TM会通知所有RM执行提交；如果任一RM准备失败，TM会通知所有RM回滚；

通过事务管理器2阶段协调资源管理器，使所有资源管理器的状态最终都是一致的，要么全部提交，要么全部回滚。

事务协调者transaction manager

   因为XA 事务是基于两阶段提交协议的，所以需要有一个事务协调者（transaction manager）来保证所有的事务参与者都完成了准备工作(第一阶段)。如果事务协调者（transaction manager）收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL 在这个XA事务中扮演的是参与者的角色，而不是事务协调者（transaction manager）。

 

3.3、2PC应用之XA

XA是X/Open组织提出的，定义了事务管理器与资源管理器之间通信的接口协议；XA协议由数据库实现，目前支持XA协议的数据库有Oracle、MySql、BD2等；

XA定义了一系列的接口：

• xa_start: 启动XA事务
• xa_end: 结束XA事务
• xa_prepare: 准备阶段，XA事务预提交
• xa_commit： 提交XA事务
• xa_rollback: 回滚XA事务

一个数据库实现XA协议之后，它就可以作为作为一个资源管理器参与到分布式事务中;

在一阶段，事务管理器协调所有数据库执行XA事务（xa_start、用户SQL、xa_end），并完成XA事务预提交（xa_prepare）；

在二阶段，如果所有数据库上XA事务预提交均成功，那么事务管理器协调所有数据库提交XA事务（xa_commit）；如果任一数据库上XA是我预提交失败，那么事务管理器会协调所有数据组回滚XA事务（xa_rollback）;

 

Mysql的XA事务分为外部XA和内部XA

外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，通俗的说就是比如我们在PHP中写代码，那么PHP书写的逻辑就是协调者。应用层负责决定提交还是回滚，崩溃时的悬挂事务。MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：网易的DDB，淘宝的TDDL等等。
内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。Binlog作为内部XA的协调者，在binlog中出现的内部xid，在crash recover时，由binlog负责提交。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。
 

PHP调用MYSQL XA事务示例

1、首先要确保mysql开启XA事务支持

SHOW VARIABLES LIKE '%xa%'
如果innodb_support_xa的值是ON就说明mysql已经开启对XA事务的支持了。 
如果不是就执行：

SET innodb_support_xa = ON

2、代码如下：

<?PHP
$dbtest1 = new mysqli("172.20.101.17","public","public","dbtest1")or die("dbtest1 连接失败");
$dbtest2     = new mysqli("172.20.101.18","public","public","dbtest2")or die("dbtest2 连接失败");

//为XA事务指定一个id，xid 必须是一个唯一值。
$xid = uniqid("");

//两个库指定同一个事务id，表明这两个库的操作处于同一事务中
$dbtest1->query("XA START '$xid'");//准备事务1
$dbtest2->query("XA START '$xid'");//准备事务2

try {
    //$dbtest1
    $return = $dbtest1->query("UPDATE member SET name='abc' WHERE id=1") ;
    if($return == false) {
       throw new Exception("库dbtest1@172.20.101.17执行update member操作失败！");
    }

    //$dbtest2
    $return = $dbtest2->query("UPDATE memberpoints SET point=point+10 WHERE memberid=1") ;
    if($return == false) {
       throw new Exception("库dbtest1@172.20.101.18执行update memberpoints操作失败！");
    }

    //阶段1：$dbtest1提交准备就绪
    $dbtest1->query("XA END '$xid'");
    $dbtest1->query("XA PREPARE '$xid'");
    //阶段1：$dbtest2提交准备就绪
    $dbtest2->query("XA END '$xid'");
    $dbtest2->query("XA PREPARE '$xid'");

    //阶段2：提交两个库
    $dbtest1->query("XA COMMIT '$xid'");
    $dbtest2->query("XA COMMIT '$xid'");
} 
catch (Exception $e) {
    //阶段2：回滚
    $dbtest1->query("XA ROLLBACK '$xid'");
    $dbtest2->query("XA ROLLBACK '$xid'");
    die($e->getMessage());
}

$dbtest1->close();
$dbtest2->close();

?>

XA的性能问题：

     XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。

3.4、2PC应用之TCC

TCC是Try、Confirm、Cancel 3个操作的缩写；

Try操作对应2PC的一阶段Prepare，Confirm对应2PC的二阶段commit，Cancel对应2PC的二阶段rollback；

这3个操作均有用户编码实现；

TCC三个操作描述：

• Try: 检测、预留资源;
• Confirm: 业务系统执行提交；默认Confirm阶段是不会出错的，只要TRY成功，CONFIRM一定成功；
• Cancel: 业务取消，预留资源释放;

用户通编码实现TCC并发布成服务，这个TCC服务就可以作为资源参与到分布式事务中；事务管理器分2阶段协调所有的TCC资源，使得所有TCC资源状态最终都是一致，要么全部提交，要么全部回滚；

TCC自编码的特性决定TCC资源管理器可以跨DB、跨应用实现资源管理，将对不同的DB访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题；

同时TCC的每一个操作对于DB来讲都是一个本地DB事务，操作结束则本地DB事务结束，数据库的资源也就被释放；这就规避了数据库层面的2PC对资源占用导致的性能低下问题；

3.5、柔性事务

单数据库事务完全遵循ACID规范，属于刚性事务，分布式事务要完全遵循ACID规范比较困难, 分布式事务属于柔性事务，满足BASE理论；

BASE描述： BA（Basic Availability 基本业务可用性）、S（Soft state 柔性状态）、E（Eventual consistency 最终一致性）

柔性事务对ACID的支持：

1、原子性：

严格遵循；

2、一致性：

事务完成后的一致性严格遵循，事务中的一致性可适当放宽；

3、隔离性：

并行事务间不可影响；事务中间结果可见性允许安全放宽；

4、持久性：

严格遵循；

为了可用性、性能的需要，柔性事务降低了一致性(C)与隔离性(I) 的要求，即“基本可用，最终一致”；

3.6、柔性事务的分类

柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型；

1、两阶段型

就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS，这是分布式环境下事务处理的典型模式。

2、补偿型

TCC型事务（Try/Confirm/Cancel）可以归为补偿型；TCC思路是:尽早释放锁；在Try成功的情况下，如果事务要回滚，Cancel将作为一个补偿机制，回滚Try操作；

TCC各操作事务本地化，且尽早提交 (放弃两阶段约束)；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为；

TCC是将资源层的两阶段提交协议转换到业务层，成为业务模型中的一部分；

3、异步确保型

将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用；比如消息事务机制；

4、最大努力通知型

通过通知服务器(消息通知)进行，允许失败，有补充机制；