彻底掌握分布式事务2PC、3PC模型（一）

分布式事务系列第一篇文章

工作中使用最多的是本地事务，但是在对单一项目拆分为 SOA、微服务之后，就会牵扯出分布式事务场景

文章以分布式事务为主线展开说明，并且针对 2PC、3PC 算法进行详细的讲解，最后通过一个 Demo 来更深入掌握分布式事务，文章目录结构如下

• 什么是事务
• 什么是分布式事务
• DTP 模型和 XA 规范
•     什么是 DTP 模型
•     什么是 XA 规范
• 2PC 一致性算法
•     2PC-准备阶段
•     2PC-提交阶段
•     2PC 算法优缺点
• 3PC 一致性算法
• JDBC 操作 MySQL XA 事务
• 结言

什么是事务
事务是数据库操作的最小工作单元，一组不可再分割的操作集合，是作为单个逻辑工作单元执行的一系列操作。这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行

事务具有四个特征，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的 ACID 特性

如何保证事务的 ACID 特性？

• 原子性（Atomicity）：事务内 SQL 要么同时成功要么同时失败，基于撤销日志（undo 日志）实现
• 一致性（Consistency）：系统从一个正确态转移到另一个正确态，由应用通过 AID 来保证，可以说是事务的核心特性
• 隔离性（Isolation）：控制事务并发执行时数据的可见性，基于锁和多版本并发控制（mvcc）实现
• 持久性（Durability）：提交后一定存储成功不会丢失，基于重做日志（redo log）实现

文章主要是介绍分布式事务 2PC 和 3PC，关于 redo、undo 日志、mvcc、锁这块的内容后续再详细介绍

在早些时候，我们应用程序还是单体项目，所以操作的都是单一数据库，这种情况下我们称之为本地事务。本地事务的 ACID 一般都是由数据库层面支持的，比如我们工作中常用的 MySQL 数据库

 
平常我们在操作 MySQL 客户端时，MySQL 会隐式对事务做自动提交，所以日常工作不会涉及手动书写事务的创建、提交、回滚等操作。如果想要试验锁、MVCC等特性，可以创建多个会话，通过begin、commit、rollback等命令来试验下不同事务之间的数据，看执行结果和自己所想是否一致

 
我们平常开发项目代码时使用的是 Spring 封装好的事务，所以也不会手动编写对数据库事务的提交、回滚等方法（个别情况除外）。这里使用原生 JDBC 写一个示例代码，帮助大家理解如何通过事务保证 ACID 四大特性

Connection conn = ...; // 获取数据库连接
conn.setAutoCommit(false); // 开启事务
try {
   // ...执行增删改查sql
   conn.commit(); // 提交事务
} catch (Exception e) {
  conn.rollback(); // 事务回滚
} finally {
   conn.close(); // 关闭链接
}

设想一下，每次进行数据库操作，都要写重复的创建事务、提交、回滚等方法是不是挺痛苦的，那 Spring 如何自动帮助我们管理事务的呢？Spring 项目中我们一般使用两种方式来进行事务的管理，编程式事务和声明式事务

项目中使用 Spring 管理事务，要么在接口方法上添加注解 @Transactional，要么使用 AOP 配置切面事务。其实这两种方式大同小异，只不过 @Transactional 的粒度更细一些，实现原理上都是依赖 AOP，举例说明下

@Service
public class TransactionalService {
  @Transactional
  public void save() {
      // 业务操作
  }
}

TransactionalService 会被 Spring 创建一个代理对象放入到容器中，创建后的代理对象相当于下述类

public class TransactionalServiceProxy {
  private TransactionalService transactionalService;
  public TransactionalServiceProxy(TransactionalService transactionalService) {
    this.transactionalService = transactionalService;
  }
  
  public void save() {
      try {
          // 开启事务操作
          transactionalService.save();
      } catch (Exception e) {
          // 出现异常则进行回滚
      }
      // 提交事务
  }
}

示例代码看着简洁明了，但是真正的代码生成代码对比要复杂很多。关于事务管理器，Spring 提供了接口 PlatformTransactionManager，其内部包含两个重要实现类

• DataSourceTransactionManager：支持本地事务，内部通过java.sql.Connection来开启、提交和回滚事务
• JtaTransactionManager：用于支持分布式事务，其实现了 JTA 规范，使用 XA 协议进行两阶段提交
  通过这两个实现类得知，平常我们使用的编程式事务和声明式事务依赖于本地事务管理实现，Spring 同时也支持分布式事务，关于 JTA 分布式事务的支持网上资料挺多的，就不在这里赘述了

什么是分布式事务
日常业务代码中的本地事务我们一直都在用，理解起来并不困难。但是随着服务化（SOA）、微服务的流行，平常我们的单一业务系统被拆分成为了多个系统，为了迎合业务系统的变更，数据库也结合业务进行了拆分

比如以学校管理系统举例说明，可能就会拆分为学生服务、课程服务、老师服务等，数据库也拆分为多个库。当这种情况，把不同的服务部署到服务器，就会有可能面临下述的服务调用

 
ServiceA 服务需要操作数据库执行本地事务，同时需要调用 ServiceB 和 ServiceC 服务发起事务调用，如何保证三个服务的事务要么一起成功或者一起失败，如何保证用户发起请求的事务 ACID 特性呢？无疑这就是分布式事务场景，三个服务的单一本地事务都无法保证整个请求的事务

分布式事务场景有很多种解决方案，以不同分类来看，强一致性解决方案、最终一致性解决方案，细分其中的方案包括2PC、3PC、TCC、可靠消息...

业界中使用较多的像阿里的 RocketMQ 事务消息、Seata XA模式、可靠消息模型这几种解决方案。不过，分布式事务无一例外都是会直接或间接操作多个数据库，而且使用了分布式事务同时也会带来新的挑战，那就是性能问题。如果为了保证强一致性分布式事务亦或者补偿方案的最终一致性，导致了性能的下降，对于正常业务而言，无疑是得不偿失的

文章转自公众号：龙台的技术笔记