事务

分布式系统，与传统单体架构系统相比，其结构复杂的多，系统间靠网络传输数据，系统存在诸多不确定因素，如硬件故障、网络波动等，都会影响整个系统的稳定性。而分布式事务更是分布式系统的一大难题，本篇将讨论业界分布式事务的几种常见解决方案。 1. 数据库事务 百度百科对事务的定义： 数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。 解读一下这个定义： 事务产生于一个数据库操作序列：一组读取或者更新数据库等操作时，事务是一种机制，来保证了最终数据的一致性， 事务是一个不可分割的单元：一组操作不能拆分，是一个整体 事务执行：要么全部执行，要么全部不执行，不能部分执行 通常，数据库的事务是通过数据库日志来保证的，所有数据库的操作都记录日志，如果数据库发生宕机，那么通过读取日志可以知道操作时需要回滚还是提交。 众所周知，数据库事务有ACID四大特性，满足ACID特性的事务，一般称之为刚性事务，常见的单体应用（单个数据源）内部都是采用刚性事务。 最常见的事务的例子就是银行转账： 2. 分布式事务 分布式事务，指的是分布式系统间完成的事务机制，百度百科定义如下： 数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。 分布式同数据库事务一样，都用以保证数据的一致性，只是事务的参与者由原来的单数据源的一组操作序列变成了分布式系统的多个子系统。 举个例子： 用户下单流程，如下图所示： 首先，订单系统订单支付完成，然后调用库存系统扣减库存，最后再调用积分系统给账户添加积分，第1、2、3步必须全部执行成功，那么下单操作才算成功，否则，有一步出现错误，那么下单操作就是失败的。与传统事务相比，分布式事务范围在数据库事务之上进行了放大，各个系统除了有本系统事务外，还需要符合整个分布式系统的事务机制，才能保证最终的数据一致性。 但是，在分布式系统中，由于其固有的复杂性，很难保证事务的ACID特性，这种刚性事务在分布式系统中不适用，这就要提到两个概念：CAP定理和BASE理论。 2.1. CAP理论 2000年，名为Eric Brewer的教授在PODC研讨会上提出了CAP：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！他还对CAP进行明确的定义： C（Consistency，一致性）：所有的节点上的数据时刻保持同步 A（Avallable，可用性）：每个请求都能接受到一个响应，无论响应成功或失败 P（Partition tolerance，分区容错性）：系统应该能持续提供服务，即使系统内部有消息丢失（分区） CAP理论的提出，揭露了分布式系统的本质。 怎么理解CAP？ 一致性，其实就是分布式系统各节点间数据达成一致；可用性，分布式系统始终保持可用，即使出现了数据不一致；分区容错性，分布式系统必须有一定的容错能力，当系统数据丢失或者某些节点不可用（分区）系统还能继续提供服务，系统容错是不可缺少的。 既然CAP三者不能同时满足，而分布式系统中，分区容错性是不可或缺的，因此，只能在CP和AP中间选择。 由于在CAP理论要求各节点数据时刻保持同步，但是这样的强一致性只能在CP中保证，而选择满足AP时无法保证，这就引出BASE理论。 2.2. BASE理论 eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。 BA: Basically Available（基本可用） S: Soft state（软状态） E: Eventually consistent（最终一致性） 显然，BASE理论满足CAP中的AP，从而舍弃了强一致性C。 满足BASE理论，放弃强一致性，数据最终达到一致的事务我们称之为柔性事务(Flexible Transactions)。 如果分布式系统满足AP，那么虽然数据不可能时刻保持一致，但是可以达到最终一致；如果满足产CP，那么分布式系统舍弃了高可用性，却可以保持数据强一致。分布式系统中，常见的两个服务注册中心Eureka、Consul，前者满足的是AP，而后者满足的是CP。 3. 分布式事务的解决方案 分布式事务解决的核心问题就是分布式系统中各个节点的数据一致性问题，选择强一致还是最终一致，需要根据具体业务需要合理做出选择。目前，常见的几种分布式事务解决方案有2PC(两阶段提交)、3PC（三阶段提交）、TCC（补偿性事务）、本地消息表等。 3.1. 2PC 两阶段提交(2PC)，其实是XA协议的标准实现，XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。 2PC事务包括几个角色：事务协调者(coordinator)、事务参与者(participant )、资源管理器(resource manager，RM)： 事务协调者：负责收集事务参与者的信息，并决定事务提交/回滚操作 事务参与者：按照事务协调者要求参与事务，可进行事务预提交、提交或者回滚操作 资源管理器：事务参与者管理的数据库 2PC将事务的管理分为两个阶段： 1、第一阶段(prepare)：事务协调者要求每个事务参与者预提交(precommit)事务，事务并不会真正提交，并反馈(vote)提交结果 2、第二阶段(commit/rollback)：事务协调者收集参与者信息，如果每个参与者都反馈可提交事务，那么协调者下发commit指令给参与者要求提交事务，否则，如果有参与者反馈回滚事务，则协调者下发abort指令要求参与者都回滚事务 通俗的讲：协调者首先发起事务，说参与者们检查一下看看各自操作是否能够正常执行啊，不管可以与否都给我一个反馈。然后，参与者检查完成，都反馈说，老大，我们都能正常执行，那么协调者就说好吧，你们都提交事务吧；如果某一个参与者说，完了，我操作执行失败了，不能提交事务，那么协调者就告诉各参与者：某个哥们儿不能提交事务，数据一致性没法保证了，你们都回滚吧！ ...

编程式事务虽然可以精确控制事务，但是事务控制代码必须侵入业务逻辑代码中，耦合度高，后期难以维护。一般而言，不需要精确控制事务，所以采用的更多的是Spring的声明式事务。 Spring声明式事务基于AOP实现，有两种事务定义方式：xml配置和注解定义，前者使用tx命名空间，后者使用@Transactional注解。 1. 事务属性 在定义事务之前，需要了解一些事务的参数，正如前边TransactionDefinition类定义的，包括传播机制、隔离级别、是否只读、事务超时等，还包括回滚规则定义等参数。 1.1. 传播机制 传播机制（propagation）定义了客户端与被调用方法之间的事务界限。简单而言，就是一个方法调用其他一个或多个方法来实现业务逻辑时，这些方法间的事务如何进行传播，这就由传播机制来决定。 Spring提供了7中传播机制，如下表所示： Table 1. 事务的7种传播机制 传播行为 说明 REQUIRED 业务方法需要在一个事务中运行。如果方法运行时，已经处在一个事务中，那么加入到该事务，否则为自己创建一个新的事务 NOT_SUPPORTED 声明方法不需要事务。如果方法没有关联到一个事务，容器不会为它开启事务。如果方法在一个事务中被调用，该事务会被挂起，在方法调用结束后，原先的事务便会恢复执行 REQUIRES_NEW 属性表明不管是否存在事务，业务方法总会为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务会被挂起，新的事务会被创建，直到方法执行结束，新事务才算结束，原先的事务才会恢复执行 MANDATORY 该属性指定业务方法只能在一个已经存在的事务中执行，业务方法不能发起自己的事务。如果业务方法在没有事务的环境下调用，容器就会抛出异常。 SUPPORTS 这一事务属性表明，方法可以受事务控制，也可以不。如果业务方法在某个事务范围内被调用，则方法成为该事务的一部分。如果业务方法在事务范围外被调用，则方法在没有事务的环境下执行 NEVER 指定业务方法绝对不能在事务范围内执行。如果业务方法在某个事务中执行，容器会抛出异常，只有业务方法没有关联到任何事务，才能正常执行 NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按REQUIRED属性执行.它使用了一个单独的事务， 这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效 注意REQUIRES_NEW和NESTED两者的区别； PROPAGATION_REQUIRES_NEW启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行. PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交. ...

前边提到，编写程序式的事务管理可以清楚的定义事务的边界，可以实现细粒度的事务控制，比如你可以通过程序代码来控制你的事务何时开始，何时结束等，它可以实现细粒度的事务控制。 1. TransactionTemplate Spring提供了TransactionTemplate对象来控制事务，它使用了一种回调机制，通过回调来修改事务状态，继承关系如下： TransactionOperations接口定义了基础的事务的执行操作execute()，该接口便于后续扩展，一般不直接使用。 在使用TransactionTemplate之前，需要声明bean： <!--JDBC事务管理器--> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <!--编程式事务配置--> <bean id="transactionTemplate" class="org.springframework.transaction.support.TransactionTemplate"> <property name="transactionManager" ref="transactionManager"/> </bean> TransactionTemplate使用PlatformTransactionManager的实现来管理事务，这里注入的是JDBC的事务管理器。事务控制代码如下： public void add(User user) throws Exception{ // Spring编码式事务，回调机制 transactionTemplate.execute(new TransactionCallback<Object>() { @Override public Object doInTransaction(TransactionStatus status) { try { userMapper.insertSelective(user); } catch (Exception e) { // 异常，设置为回滚 status.setRollbackOnly(); throw e; } return null; } }); } 调用TransactionTemplate的execute()方法，传递一个TransactionCallback接口的实现，执行其doInTransaction()方法，该方法会回传事务状态对象TransactionStatus，如果有异常，则调用status.setRollbackOnly()将事务状态标记为回滚，否则doInTransaction方法正常返回，事务则会提交。 如果事务控制的方法不需要返回值，那么可以使用TransactionCallback接口的抽象实现类TransactionCallbackWithoutResult： @Override public void add(User user) throws Exception { // Spring编码式事务，回调机制 transactionTemplate.execute(new TransactionCallbackWithoutResult() { @Override protected void doInTransactionWithoutResult(TransactionStatus status) { try { userMapper.insertSelective(user); } catch (Exception e) { // 异常，设置为回滚 status.setRollbackOnly(); throw e; } } }); } ...

前边简单介绍了事务的概念和其ACID特性，现在让我们看看Spring是如何实现对事务的支持的。 1. Spring事务管理器结构 Spring并不直接管理事务，而是提供多种事务管理器，将管理事务的责任委托给JTA或相应的持久性机制所提供的某个特定平台的事务实现。 Spring对事务管理器的抽象： Spring提供了顶层接口PlatformTransactionManager，并提供了扩展接口ResourceTransactionManager和抽象实现类AbstractPlatformTransactionManager。PlatformTransactionManager下的所有接口和实现类如图所示： 一般而言，每一种事务实现的类图如下： PlatformTransactionManager是Spring事务管理器的核心，接口定义如下： public interface PlatformTransactionManager { // 返回一个已经激活的事务或创建一个新的事务（根据给定的TransactionDefinition类型参数定义的事务属性）， // 返回的是TransactionStatus对象代表了当前事务的状态，其中该方法抛出TransactionException（未检查异常） // 表示事务由于某种原因失败。 TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException; // 提交给定的事务，检查其状态。如果事务被标记为rollback-only，则执行回滚。 // 如果事务不是新的事务，则忽略提交周围适当的事务。如果先前的事务被挂起，则在提交新事务后恢复先前的事务。 void commit(TransactionStatus status) throws TransactionException; // 执行给定事务的回滚。如果事务不是一个新的事务，将其周边适当的事务标记为rollback-only。 // 如果先前的事务被挂起，则在回滚新事务后恢复先前的事务。 void rollback(TransactionStatus status) throws TransactionException; } TransactionDefinition接口定义如下： public interface TransactionDefinition { // 返回事务传播行为 int getPropagationBehavior(); // 返回事务隔离级别 int getIsolationLevel(); // 返回事务超时时间 int getTimeout(); // 返回事务是否只读 boolean isReadOnly(); // 返回事务的名称 String getName(); } ...

1. 定义 在软件开发领域， 全有或全无的操作被称为事务（transaction）。 事物允许将几个操作组合成一个要么全部发生要么全部不发生的工作单元。发生和不发生两者只能选择其一，而不可能两者都选择。事务确保了数据和资源免于处在不一致的状态。 让我们继续使用最简单有效的转账例子来说明事务： A给B转100元，这个过程大概需要两步： step1、从A的账户扣除100元； step2、给B的账户增加100元。 这两步必须要么全部执行成功要么都不成功并且还原账户的金钱为初始值，否则转账失败。如果step1成功而step2失败，那么A账户少了100元，但是B却没收到钱；如果step1失败而step2成功，B账户会多出100元。这两种情况都是不允许发生的。 所以，step1和step2必须处于同一事务中，我们就说事务把这两个操作组合为要么都成功要么都失败的工作单元。整个操作成功，那么转账成功，结果是A账户扣了100元而B账户多了100元；如果整个过程失败，那么A和B的账户的金额恢复到转账前的状态，即未发生任何变化，就像转账操作从未发生过一样。 2. ACID特性 Atomic(原子性)：确保所有操作要么都发生，要么都不发生。 Consistent(一致性)：事务前后，数据均处于正确状态，数据不应该被破坏。 Isolated(隔离性)：事务彼此隔离，用户间操作不相混淆。 Durable(持久性)：事务一旦完成，结果应该持久化，例如保存到数据库中。 上边转账的例子中，两步操作必须要么成功要么都失败，确保了原子性；而原子性保证账户中的金额不会处于不一致或者说部分完成，保证了一致性；转账过程与其他转账过程互不影响，遵循隔离性；转账成功后，结果必须持久化保存，防止事务结果丢失。 3. Spring对事务管理的支持 Spring提供两者事务管理方式：编程式事务管理和声明式事务管理。 3.1. 编程式事务管理 编写程序式的事务管理可以清楚的定义事务的边界，可以 实现细粒度的事务控制，比如你可以通过程序代码来控制你的事务何时开始，何时结束等，与后面介绍的声明式事务管理相比，它可以实现细粒度的事务控制。 3.2. 声明式事务管理 如果你并不需要细粒度的事务控制，你可以使用声明式事务，在Spring中，你只需要在Spring配置文件中做一些配置，即可将操作纳入到事务管理中， 解除了和代码的耦合， 这是 对应用代码影响最小的选择，从这一点再次验证了Spring关于 AOP的概念。当你不需要事务管理的时候，可以直接从Spring配置文件中移除该设置。 Spring通过回调机制将实际的事务实现从事务性代码中抽象出来。如果应用只使用一种持久化资源，那么可以使用持久化机制本身的事务性支持（JDBC、Hibernate、JPA等）；如果应用事务跨多个资源，那么Spring会使用第三方的JTA(JAVA事务API)实现来支持分布式(XA)事务。 使用声明式事务还是编程式事务管理，在很大程度上是 细粒度和易用性之间权衡。一般情况下，不需要精确控制事务，采用声明式事务不仅易用性高，而且降低了事务与其他业务代码的耦合性。 4. 总结 在软件开发领域，全有或全无的操作被称为事务。事务必须具备ACID特性，在Spring中，除了编程来精确控制事务，还可以使用AOP来配置低耦合度的声明式事务控制。