关于数据安全:保护亿万数据安全Spring有声明式事务绝招

42次阅读

共计 10345 个字符,预计需要花费 26 分钟才能阅读完成。

摘要:点外卖时,你只需思考如何拼单;抉择出行时,你只用想好目的地;手机领取时,你只须要保障余额短缺。但你不晓得这些智能的背地,是数以亿计的弱小数据的反对,这就是数据库的力量。那么宏大数据的背地肯定会牵扯到数据安全的问题,那这些意外和抵触又是如何解决呢?

本文分享自华为云社区《万字详解 Spring 如何用“申明式事务”爱护亿万数据安全?丨【绽开吧!数据库】》,作者:灰小猿。

一、揭秘什么是事务管理?

理解申明式事务就要从它的基本概念开始。那么什么是事务呢?

在 JavaEE 的大型项目开发中,面对规模宏大的数据,须要保证数据的完整性和一致性,因而就有了数据库事务的概念,因而它也是企业级我的项目利用开发必不可少的技术。

事务能够看做是一组因为逻辑上严密相干而合并到一个整体(工作单元)的多个数据库操作。这些操作要么全执行,要么全不执行。

同时事务有四个十分要害的属性(ACID):

  1. 原子性(atomicity):“原子”的本意是“不可再分”,事务的原子性体现为一个事务中波及到的多个操作在逻辑上缺一不可。事务的原子性要求事务中的所有操作要么都执行,要么都不执行。
  2. 一致性(consistency):“统一”指的是数据的统一,具体是指:所有数据都处于满足业务规定的一致性状态。一致性准则要求:一个事务中不论波及到多少个操作,都必须保障事务执行之前数据是正确的,事务执行之后数据依然是正确的。如果一个事务在执行的过程中,其中某一个或某几个操作失败了,则必须将其余所有操作撤销,将数据恢复到事务执行之前的状态,这就是回滚。
  3. 隔离性(isolation):在应用程序理论运行过程中,事务往往是并发执行的,所以很有可能有许多事务同时解决雷同的数据,因而每个事务都应该与其余事务隔离开来,避免数据损坏。隔离性准则要求多个事务在并发执行过程中不会相互烦扰。
  4. 持久性(durability):持久性准则要求事务执行实现后,对数据的批改永恒的保留下来,不会因各种零碎谬误或其余意外状况而受到影响。通常状况下,事务对数据的批改应该被写入到长久化存储器中。

所以进行事务管制就应该尽可能的满足这四个属性。既然进行事务管制的目标就是为了可能在数据处理发生意外的时候进行事务回滚,那么常见的谬误类型有哪些、对于这种类型的谬误又应该如何解决的呢?

二、申明式事务应用详解

相比于编程式事务,申明式事务具备更大的长处,它可能将事务管理代码从业务办法中分离出来,以申明的形式来实现业务管理。

事务管理代码的固定模式作为一种横切关注点,能够通过 AOP 办法模块化,进而借助 Spring AOP 框架实现申明式事务管理。

Spring 在不同的事务管理 API 之上定义了一个 形象层 ,通过配置的形式使其失效, 从而让应用程序开发人员不用理解事务管理 API 的底层实现细节,就能够应用 Spring 的事务管理机制

同时 Spring 既反对编程式事务管理,也反对申明式的事务管理。

那么在 Spring 中应该如何应用申明式事务呢?

1、事务管理器的次要实现

Spring 从不同的事务管理 API 中形象出了一整套事务管理机制,让事务管理代码从特定的事务技术中独立进去。这样咱们只需通过配置的形式进行事务管理,而不用理解其底层是如何实现的。这也是应用申明式事务的一大益处。

Spring 的外围事务管理形象是 PlatformTransactionManager。它为事务管理封装了一组独立于技术的办法。无论应用 Spring 的哪种事务管理策略(编程式或申明式),事务管理器都是必须的。

事务管理器能够以一般的 bean 的模式申明在 Spring IOC 容器中。在 Spring 中咱们罕用的三种事务管理器是:

  1. DataSourceTransactionManager:在应用程序中只须要解决一个数据源,而且通过 JDBC 存取。
  2. JtaTransactionManager:在 JavaEE 应用服务器上用 JTA(Java Transaction API)进行事务管理
  3. HibernateTransactionManager:用 Hibernate 框架存取数据库

它们都是 PlatformTransactionManager 的子类,继承关系图如下:

当初咱们曾经根本理解了申明式事务的实现原理和机制,百读不如一练,接下来咱们就理论解说一下如何配置应用 Spring 的申明式事务。

2、基于注解的申明式事务配置

我以 DataSourceTransactionManager 类为例来给大家讲一下申明式事务的实现过程,小伙伴们能够操作实现一下,有问题的话记得留言我一起交换。

(1)、配置数据源

既然是对数据库的操作,那么首先第一步肯定就是配置数据源的,对于数据源的配置置信小伙伴们应该都不生疏了,还不太理解的小伙伴们能够看我的上一篇对于 Spring 的文章。《Spring JDBC 长久化层框架“全家桶”教程丨【绽开吧!数据库】》

配置数据源我以引入内部数据配置文件为例,所以我这里须要应用 <context></context> 标签引入内部文件,并应用“${}”的形式为属性赋值:

代码如下:

<!-- 连贯内部配置文件 -->
<context:property-placeholder location="classpath:jdbcconfig.properties"/>

<!-- 连贯数据库 -->
<bean id="pooldataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
    <property name="user" value="${jdbc.user}"></property>
    <property name="password" value="${jdbc.password}"></property>
    <property name="jdbcUrl" value="${jdbc.jdbcurl}"></property>
    <property name="driverClass" value="${jdbc.driverclass}"></property>
</bean>

(2)、建设 JdbcTemplate

既然是操作数据库,而且是在 spring 框架中,那么对于 Spring 中数据库操作框架的应用也肯定是必不可少的,对于 jdbcTemplate 这个框架技术点的具体应用我也在上一篇文章中和大家解说了,小伙伴们能够学起来了!

在这里咱们间接在 ioc 的 bean 中申明 jdbcTemplate 类,并设置数据源为第一步的数据源。

代码如下:

<!-- 建设 jdbcTemplate -->
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    <property name="dataSource" ref="pooldataSource"></property>
</bean>

(3)、进行事务管制

当初数据源也配置好了,数据库操作也整完了,那么接下来就是明天的主题事务管制了。

咱们晓得事务管制自身就是基于面向切面编程来实现的,所以配置事务管制时就须要导入相应的 jar 包:我把所需的 jar 包给大家列举了进去:

• spring-aop-4.0.0.RELEASE.jar
• com.springsource.net.sf.cglib-2.2.0.jar
• com.springsource.org.aopalliance-1.0.0.jar
• com.springsource.org.aspectj.weaver-1.6.8.RELEASE.jar

在这里插入一个补充,也能够说是一道面试题:说一说应用事务管理器的长处?

应用事务管制可能节俭平时进行事务管制是书写的代码量,进行事务管制时,若一个事务的执行过程中产生过错,则其余操作不会批改,放弃事务的原子性。

咱们在这里应用 DataSourceTransactionManager 类来配置事务管理器。

具体方法是在 ioc 中的 bean 标签中申明该类的实例,设置好 id,并给 DataSource 属性赋上数据源,

代码如下:

    <bean id="dataSourceTransactionManager"  class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <!-- 2、管制住数据源 -->
        <property name="dataSource" ref="pooldataSource"></property>
    </bean>

这样就曾经配置好事务管理器了,是不是认为这样就完了,并没有噢!接下来也是最要害的一步!就是将事务管理器开启,因为不开启怎么应用呢?

(4)、开启基于注解的事务管制

开启基于注解的事务管制的次要作用就是 对办法和类减少相应的注解,从而实现主动的包扫描。开启基于注解的事务管制须要引入 tx 表达式,应用其中的 annotation-driven 标签,即可对执行的事务管理器开启事务管制。

代码如下:

<!-- 3、开启基于注解的事务管制 -->    
<tx:annotation-driven transaction-manager="dataSourceTransactionManager"/>
<!-- 4、给办法减少事务管制,增加相应的注解 -->

接下来的就是为办法增加相应的注解,减少事务管制了。

首先对数据库操作的类个别都属于业务逻辑层,所以咱们要为该类增加 @service 注解,从而实现包扫描,之后为须要进行事务管制的办法增加事务管制专有的注解@Transactional 来通知 Spring 该办法是事务办法。当该办法中的操作产生谬误的时候,该办法内其余对数据库的操作也都会回滚。

代码如下:

@Service
public class BookService {
    @Autowired
    BookDao bookDao;
    /**
     * 顾客买书
     * */
//    开启基于注解的事务管制
    @Transactional
    public void buyBook(String username,String isbn) {bookDao.updateStockFromBookStock(isbn);
        int price = bookDao.getPriceFromBook(isbn);
        bookDao.updateBalanceFromAccount(username, price);
        System.out.println("【" +username +  "】买书胜利!");
    }
 
}

3、基于 XML 的申明式事务配置

下面咱们解说了应用注解如何配置申明式事务,那么配置申明式事务还有另一种办法,就是在 XML 文件中配置,而且他们在申明数据源的时候都是一样的,在这里我就不说了,我只说一下在配置完数据源之后,如何通过 XML 申明事务管理器和事务办法。

(1)、配置事务切面

Spring 中有提供事务管理器(事务切面),所以首先咱们须要配置这个事务切面。

<aop:config>
    <aop:pointcut expression="execution(* com.spring.service.*.*(..))" id="txpoint"/>
    <!-- 事务倡议;advice-ref: 指向事务管理器的配置 -->
    <aop:advisor advice-ref="myAdvice" pointcut-ref="txpoint"/>
</aop:config>

(2)、配置事务管理器

配置事务管理器应用 tx:advice 标签,其中的属性 transaction-manager=”transactionManager” 指定是配置哪个事务管理器,指定好之后咱们就须要在该标签中配置出事务办法,

<!-- 配置事务管理器
        transaction-manager="transactionManager" 指定是配置哪个事务管理器
     -->
    <tx:advice id="myAdvice" transaction-manager="dataSourceTransactionManager">

    </tx:advice>

(3)、指定事务办法

咱们须要在 tx:advice 标签中减少 tx:method 标签通知 Spring 哪些办法是事务办法(事务切面将依照咱们的切入点表达式去切事务办法)。同时事务能够应用的各种参数能够在 tx:method 中申明,

代码如下:

<!-- 配置事务管理器
        transaction-manager="transactionManager" 指定是配置哪个事务管理器
     -->
    <tx:advice id="myAdvice" transaction-manager="dataSourceTransactionManager">
        <!-- 事务属性 -->
        <tx:attributes>
            <!-- 指明哪些办法是事务办法,切入点表达式只是说,事务管理器要切入这些办法,-->
            <!-- 指定所有的办法都是事务办法 -->
            <tx:method name="*"/>
            <!-- 仅仅指定一个办法是事务办法,并且指定事务的属性 -->
            <tx:method name="buyBook" propagation="REQUIRED" timeout="-1"/>
            <!-- 示意所有以 get 结尾的办法 -->
            <tx:method name="get*" read-only="true"/>
        </tx:attributes>
    </tx:advice>

至此申明式事务的初步应用才算实现,那么到底什么时候应用基于注解的事务管理器,什么时候应用基于 XML 的呢,

留神:正确的应该是, 基于注解的和基于注解的都用,重要的事务应用注解,不重要的事务应用配置。

你认为到这里就完结了嘛?然而这仅仅只是一个开始,因为事务的管制肯定是随同着多种状况一起执行的。

三、事务的流传行为

当一个事务办法被另一个事务办法调用时,必须指定事务应该如何流传。例如:办法可能持续在现有事务中运行,也可能开启一个新事务,并在本人的事务中运行。

事务的流传行为能够在 @Transactional 注解的 propagation 属性中指定。Spring 定义了 7 品种流传行为。

他们所对应的性能别离如下表所示:

这里我再对最常应用的两个流传行为说一下:

1)REQUIRED:以后事务和之前的大事务专用一个事务

当事务应用 REQUIRED 的时候,事务的属性都是集成于大事务的,所以对办法施加的属性不会独自失效如超时设置 timeout。

当事务应用 REQUIRES_NEW 的时候,事务的属性是能够调整的,

2)REQUIRES_NEW:以后事务总是应用一个新的事务,如果曾经有事务,事务将会被挂起,以后事务提交运行完之后会持续运行被挂起的事务

原理:REQUIRED,是将之前事务的 connection 传递给这个办法应用。

REQUIRES_NEW,是这个办法间接应用新的 connection

四、事务的隔离级别

1、数据库事务并发问题

咱们在对数据库中的数据进行操作的时候,往往不是只有一个人在操作的,也就是说可能会有事务的并发执行,那么既然存在并发执行,在这其中就肯定会存在并发解决的问题。

那么都会有哪些常见的事务并发问题呢?咱们以两个事务 Transaction01 和 Transaction02 并发执行为例来介绍一下:

(1)、脏读

所谓脏读就是读取到了一个脏的数据,艰深一点了解为就是读取到的数据有效。** 如上面的操作实例:
**

  1. Transaction01 将某条记录的 AGE 值从 20 批改为 30。
  2. Transaction02 读取了 Transaction01 更新后的值:30。
  3. Transaction01 回滚,AGE 值复原到了 20。
  4. Transaction02 读取到的 30 就是一个有效的值。

这时 Transaction02 的事务就产生了脏读,

(2)、不可反复读

从外面意思上咱们应该也能够了解,就是同一个事务在对数据进行反复读取的时候,两次读取到的数据不统一。

看上面的案例:

  1. Transaction01 读取了 AGE 值为 20。
  2. Transaction02 将 AGE 值批改为 30。
  3. Transaction01 再次读取 AGE 值为 30,和第一次读取不统一。

这时 Transaction01 两次读取到的数据不统一,这就到之后 Transaction01 处理事务时会呈现不晓得应用哪个数据的状况,这就是不可反复读。

(3)、幻读

听到这个名字是不是感觉很神奇,怎么还会有幻读呢?其实幻读的意思还是两次读取到的数据不统一,

看上面的案例:

  1. Transaction01 读取了 STUDENT 表中的一部分数据。
  2. Transaction02 向 STUDENT 表中插入了新的行。
  3. Transaction01 读取了 STUDENT 表时,多出了一些行。

在这里 Transaction01 在第二次读取数据表时,发现数据表中的数据和之前的相比多了,这就是产生了幻读。

2、事务的隔离级别剖析

那么对于咱们下面提到的那三种并发问题到底应该如何解决呢?这里就用到了事务的隔离级别,因为这些问题都是因为并发执行而引起的,因而数据库系统必须具备隔离并发运行各个事务的能力,使它们之间不会相互影响,防止各种并发问题。

一个事务与其余事务隔离的水平就称为隔离级别。SQL 规范中规定了多种事务隔离级别,不同隔离级别对应不同的烦扰水平,隔离级别越高,数据一致性就越好,但并发性越弱。

常见的隔离级别有以下四种:

  1. ①读未提交:READ UNCOMMITTED
    容许 Transaction01 读取 Transaction02 未提交的批改。
  2. ②读已提交:READ COMMITTED
    要求 Transaction01 只能读取 Transaction02 已提交的批改。
  3. ③可反复读:REPEATABLE READ
    确保 Transaction01 能够屡次从一个字段中读取到雷同的值,即 Transaction01 执行期间禁止其它事务对这个字段进行更新。
  4. ④串行化:SERIALIZABLE

确保 Transaction01 能够屡次从一个表中读取到雷同的行,在 Transaction01 执行期间,禁止其它事务对这个表进行增加、更新、删除操作。能够防止任何并发问题,但性能非常低下。
然而这些个隔离级别并不是都能解决下面所有的并发问题的,他们解决并发问题的能力如下:

同时不同的数据库对不同隔离级别也是有不同的反对水平,就拿 MySQL 和 Oracle 为例:

3、为办法指定隔离级别

咱们下面讲了事务并发的问题,也提到了应该应用隔离级别来解决,那么接下来就是如何在事务办法上减少隔离级别了。在这里有两种办法。

(1)、基于注解指定隔离级别

基于注解指定事务隔离级别能够在 @Transactional 注解申明式地治理事务时,在 @Transactional 的 isolation 属性中设置隔离级别。这样该事务办法就有了该隔离级别。

@Transactional(readOnly=true,isolation=Isolation.READ_UNCOMMITTED)
public int getPrice(String isbn) {return bookDao.getPriceFromBook(isbn);
}

(2)。基于 XML 指定隔离级别

这种办法是在如果不应用注解的状况下,能够在 XML 配置文件中为办法申明隔离级别,能够在 Spring 2.x 事务告诉中,在 <tx:method> 元素中的 isolation 属性指定隔离级别。如下:

<tx:advice id="myAdvice" transaction-manager="dataSourceTransactionManager">
    <!-- 事务属性 -->
    <tx:attributes>
        <tx:method name="buyBook" propagation="REQUIRED" isolation="READ_COMMITTED"/>
    </tx:attributes>
</tx:advice>

五、触发事务回滚的异样

咱们下面只是说在产生谬误时进行回滚,那么是否能够指定只有在产生特定谬误的状况下能力产生回滚呢?当然是能够的。

1、默认回滚异样

在默认状况下:

零碎捕捉到 RuntimeException 或 Error 时回滚,而捕捉到编译时异样不回滚。

然而当初咱们能够通过某一个属性来指定只有在产生某一个或某多个谬误时才回滚。

2、设置特定异样下回滚

设置特定异样下回滚同样是能够在注解中或者在 XML 中申明,

(1)、通过注解设置回滚

通过注解设置回滚的话,同样是在 @Transactional 注解下,有两个属性:

rollbackFor 属性:指定遇到时必须进行回滚的异样类型,能够为多个
noRollbackFor 属性: 指定遇到时不回滚的异样类型,能够为多个

当设置多个的时候应用大括号 {} 扩住,应用逗号隔开。

如下:

@Transactional(propagation=Propagation.REQUIRED,rollbackFor={IOException.class,SQLException.class},
noRollbackFor={ArithmeticException.class,NullPointerException.class})
public void updatePrice(String isbn,int price) {bookDao.updatePrice(isbn, price);
}

(2)、通过 XML 设置回滚

在 Spring 2.x 事务告诉中,能够在 <tx:method> 元素中指定回滚规定。如果有不止一种异样则用逗号分隔。

<!-- 配置事务管理器
transaction-manager="transactionManager" 指定是配置哪个事务管理器 -->
<tx:advice id="myAdvice" transaction-manager="dataSourceTransactionManager">
<!-- 事务属性 -->
    <tx:attributes>
        <tx:method name="get*" read-only="true" rollback-for="java.io.IOException, java.sql.SQLException"
no-rollback-for="java.langArithmeticException"/>
    </tx:attributes>
</tx:advice>

六、事务的超时和只读属性

因为事务能够在行和表上取得锁,因而长事务会占用资源,并对整体性能产生影响。

如果一个事物只读取数据但不做批改,数据库引擎能够对这个事务进行优化。应用 readOnly=true 即可(面试考点,如何在获取数据上进行优化?)

所以这里就引入了两个属性:

超时事务属性:事务在强制回滚之前能够放弃多久。这样能够避免长期运行的事务占用资源。应用属性 timeout

只读事务属性: 示意这个事务只读取数据但不更新数据, 这样能够帮忙数据库引擎优化事务。应用属性 readOnly

设置这两个属性同样是能够通过注解或者 XML 形式。

1、注解设置超时和只读

通过注解设置超时和回滚的话,是在 @Transactional 注解下应用 timeout 属性和 readOnly 属性,

readOnly:只读的,参数是 boolean;类型,设置事务为只读事务(只能够进行查问操作,对数据库有批改的操作不会被执行)对事务进行优化时能够应用 readOnly=true,这样能够减少查问速度,疏忽事务相干操作

Timeout:超时,参数是 int(以秒为单位),事务超出指定执行时长后主动终止并回滚,参数是“-1”(或小于 0)示意永不超时。

超时时会报错:TransactionTimedOutException: Transaction timed out:

实例代码如下:

@Transactional(timeout=3,readOnly=false,propagation=Propagation.REQUIRES_NEW)
public void buyBook(String username,String isbn){bookDao.updateStockFromBookStock(isbn);
    int price = bookDao.getPriceFromBook(isbn);
    bookDao.updateBalanceFromAccount(username, price);
    System.out.println("【" +username +  "】买书胜利!");
}

2、XML 设置超时和只读

在 Spring 2.x 事务告诉中,超时和只读属性能够在 <tx:method> 元素中进行指定,同样也是应用 timeout 和 readOnly 两个属性。

代码如下:

<!-- 配置事务管理器
transaction-manager="transactionManager" 指定是配置哪个事务管理器 -->
<tx:advice id="myAdvice" transaction-manager="dataSourceTransactionManager">
<!-- 事务属性 -->
    <tx:attributes>
        <tx:method name="get*" read-only="true"  timeout="3"/>
    </tx:attributes>
</tx:advice>

七、写在最初

直到这里,Spring 中申明式事务管理器的应用教程才算齐全完结了,然而其中还有很多细节须要咱们在理论的开发中发现。

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0