Transaction事务使用了解

1.功能概述

​ 在wiki的解释中，事务是一组单元化的操作，这组操作可以保证要么全部成功，要么全部失败（只要有一个失败的操作，就会把其他已经成功的操作回滚）。

​ 这样的解释还是不够直观，看下面一个经典的例子。假设有两个银行账户A和B，现在A要给B转10块钱，也就是转账。在银行系统中A和B是两个独立的账户，所以转账操作会被分解：

1. 从A的账户中扣掉10块钱
2. 在B的账户中添加10块钱

​ 通过事务机制可以保证数据库的一致性和完整性。事务具有四个基本特点，即ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

​ 现今互联网界，分布式系统和微服务架构盛行。业界著名的CAP理论也告诉我们，在设计和实现一个分布式系统时，需要将数据一致性、系统可用性和分区容忍性放在一起考虑。iGIX/GS Cloud 根据使用场景的不同，将事务分成了几大类，并提供不同的解决方案。

1.数据库事务

2.微服务间最终一致性

3.微服务间强一致性

本文仅介绍数据库的事务方案，不涉及微服务间的一致性处理。

2.事务介绍

数据库的事务方案主要采用的是Spring的事务管理。Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。
Spring事务管理涉及的接口的联系如下：

Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。
Spring事务管理器的接口是org.springframework.transaction.PlatformTransactionManager，通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

3.使用说明

支持两种事务使用方式：编程式和注解式。注解式开发效率更高，但编程式在启动环节效率更高、适应性更强。所以从产品整体角度触发，优先推荐使用编程式事务。
一、编程式事务方式（推荐）:
编程式事务 (Java)

注意：在Java中Exception和Error都派生自Throwable，捕获时最好使用Throwable，以避免不全面导致事务未提交。
二、事务注解方式: @Transactional

注解位置

1.在类上加注解(对整个类起作用）

@Transactional
public class TestDaoImpl implements TestDao {

    public List getList() {

        return null;
    }
}

2.加在方法上（只对整个方法起作用）：

public class TestDaoImpl implements TestDao {

    @Transactional
    public List getList() {
        return null;
    }
}

传播行为介绍

//如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)
@Transactional(propagation=Propagation.REQUIRED) 
//容器不为这个方法开启事务
@Transactional(propagation=Propagation.NOT_SUPPORTED) 
//不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务
@Transactional(propagation=Propagation.REQUIRES_NEW) 
//必须在一个已有的事务中执行,否则抛出异常
@Transactional(propagation=Propagation.MANDATORY) 
//必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)
@Transactional(propagation=Propagation.NEVER) 
//如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务.
@Transactional(propagation=Propagation.SUPPORTS) 
//如果有活动事务，运行在潜逃的事务中，没有活动事务，则按Propagation.REQUIRED属性执行
@Transactional(propagation=Propagation.NESTED) 

@Transactional注解中常用参数说明

参数名称 功能描述

readOnly 该属性用于设置当前事务是否为只读事务，设置为true表示只读，false则表示可读写，默认值为false。
例如：@Transactional(readOnly=true)

rollbackFor 该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。
例如：
指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)
指定多个异常类：@Transactional(rollbackFor={RuntimeException.class,Exception.class})

rollbackForClassName 该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。
例如：
指定单一异常类名称：@Transactional(rollbackForClassName="RuntimeException") 
指定多个异常类名称：@Transactional(rollbackForClassName={"RuntimeException","Exception"})

noRollbackFor
该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。
例如：
指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)
指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class,Exception.class})

noRollbackForClassName 该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。
例如：
指定单一异常类名称：@Transactional(noRollbackForClassName="RuntimeException")
指定多个异常类名称@Transactional(noRollbackForClassName={"RuntimeException","Exception"})

propagation 该属性用于设置事务的传播行为，具体取值可参考表6-7。
例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)

isolation 该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置

timeout 该属性用于设置事务的超时秒数，默认值为-1表示永不超时

注意事项：

• 如果类或成员添加了@Transactional注解，该类必须注册为Bean，并且必须从容器中获取对象实例，原因是@Transactional注解底层使用的是动态代理来进行实现的。
• @Transactional 只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能.
• 用 spring 事务管理器,由spring来负责数据库的打开,提交,回滚.默认遇到运行期例外(throw new RuntimeException(“注释”);)会回滚，即遇到不受检查（unchecked）的例外时回滚；
  而遇到需要捕获的例外(throw new Exception(“注释”);)不会回滚,即遇到受检查的例外（就是非运行时抛出的异常，编译器会检查到的异常叫受检查例外或说受检查异常）时，需我们指定方式来让事务回滚要想所有异常都回滚,要加上@Transactional( rollbackFor={Exception.class,其它异常}) .如果让unchecked例外不回滚： @Transactional(notRollbackFor=RunTimeException.class)
• 如下:@Transactional(rollbackFor=Exception.class) //指定回滚,遇到异常Exception时回滚

• public void methodName() {
  　　　throw new Exception("注释");
  }

• @Transactional(noRollbackFor=Exception.class)//指定不回滚,遇到运行期例外(throw new RuntimeException(“注释”);)会回滚

• public ItimDaoImpl getItemDaoImpl() {
  　　　throw new RuntimeException("注释");
  }

• @Transactional 注解应该只被应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不会展示已配置的事务设置。
• @Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。然而，请注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅 是一种元数据，能够被可以识别 @Transactional 注解和上述的配置适当的具有事务行为的beans所使用。上面的例子中，其实正是 元素的出现 开启 了事务行为。
• Spring团队的建议是你在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，
  但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，

而且对象也将不会被事务代理所包装（将被确认为严重的）。因此，请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。

示例：

结果：在调用类中使用this调用本类中的另外一个添加了@Transactional注解的方法，此时this调用的方法上的@Transactional注解是不起作用的。

原因：Spring增强的是方法，不是整个类，this调用的仍是增强前的方法。

正确的做法：

4.相关规范

1.优先使用数据库事务，当不得不使用分布式事务时，才考虑使用分布式事务。

(1) 数据库事务能够保证一个数据库实例、同一会话内事务，运行性能较高，对系统资源的消耗较少。
(2) 分布式事务可以协调多个不同数据库实例，并保持事务特性。但是对资源消耗大，执行效率差，在并发业务中容易出现性能瓶颈。

2.同一微服务单元（MSU）内的数据库操作使用数据库事务，跨MSU的数据库操作优先使用EventBus(EBS)异步调用，将长事务进行拆分。

3.尽量避免使用分布式事务。

4.当使用编程式事务时，务必保证事务正确的提交或在发生异常后回滚。

5.尽量缩短事务的执行时间及操作数据的范围，避免在事务中包含不必要的数据操作。

①事务应启动的尽可能的晚，对数据的校验检查、业务参数获取、数据准备，文件I/O等操作放到事务启动之前。

②尽量避免在事务范围内进行业务逻辑和数据提交的交叉执行。例如：假设业务提供了一个单据批量保存方法（业务场景：要保证批量的单据全部保存成功，不允许部分成功部分失败）

③事务应及早提交，应避免把一些不必要保证数据完整性的后处理操作放到事务范围内执行。

④从保证数据的一致性、完整性的角度合理划分事务的粒度，避免将两个或两个以上的相对独立的事务放到同一个事务中。譬如：单据保存时的单据编号生成

7.在事务的数据处理中，要尽可能的保证相同的数据存取顺序，避免由于顺序不一致造成不必要的冲突和死锁

9.通过线程锁来减少数据库锁带来的冲突。如果程序中对某个数据表的数据访问时必须要保证串行化，则可以通过线程锁的方式，减少数据库的加锁冲突，提高程序处理效率。

如果在业务逻辑中添加线程锁，可以保证在一台应用服务器上的并发是串行的，从而减少数据库的锁冲突（线程锁比数据库锁处理效率高）