数据库事务实现原理

ACID:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)

原子性:是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。

一致性:是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。

隔离性:是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

持久性:是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

个人理解据库事务主要做了两件事情：
一是保证一致性结果,能在发生异常的时候快速恢复,也就是回滚
二是并发访问的时候提供隔离

隔离级别	脏读	不可重复读	幻读
未提交读Read Uncommitted	是	是	是
已提交读Read Committed	否	是	是
可重复读Repeatable Read	否	否	是
可串行化Serializable	否	否	否

读未提交：就是一个事务可以读取另一个未提交事务的数据。
读提交：就是一个事务要等另一个事务提交后才能读取数据。若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。
重复读：就是在开始读取数据（事务开启）时，不再允许修改操作。重复读可以解决不可重复读问题。写到这里，应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。
Serializable:是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。
mysql 对应的InnoDB默认隔离级别是 重复读
明细可以参考:https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html

隔离怎么实现？
隔离的实现也是依赖加锁机制, InnoDB存在两种锁:
共享锁（S锁） ：（插入/修改/删除）资源获取S锁之后，能加S锁，不能加X锁
排它锁（X锁） ： 资源加上X锁之后，不能加S锁，也不能加X锁

S/X锁兼容表

锁定类型	读锁	写锁
读锁	Compatible	Conflict
写锁	Conflict	Conflict

具体的四种隔离级别锁实现:

隔离级别	操作	锁	生命周期
读未提交	读	否
读未提交	写	行级排它锁	立即释放
读已提交	读	行级共享锁	立即释放
读已提交	写	行级排它锁	事务结束
可重复读	读	行级共享锁	事务结束
可重复读	写	行级排它锁	事务结束
可串行化	读	范围锁/表级别锁	事务结束
可串行化	写	行级排它锁	事务结束

读未提交
为了解决丢失更新问题,需要对写操作加 X 锁

读已提交
为了保证读已提交，读操作加上 S 锁，这样如果其他事务有正在写的操作，必须等待写操作提交之后才能读，因为 S 和 X 互斥，如果在读的过程中其他事务想写，也必须等事务读完之后才可以。这里的 S 锁是一个临时 S 锁，表示事务读完之后立即释放该锁，可以让其他事务继续写，如果事务再读的话，就可能读到不一样的记录，这就是 不可重复读 了。

可重复读
为了让事务可以重复读，加在读操作的 S 锁变成了持续 S 锁，也就是直到事务结束时才释放该锁，这可以保证整个事务过程中，其他事务无法进行写操作，所以每次读出来的记录是一样的。

可串行化
序列化隔离级别下单纯的使用行锁已经实现不了，因为行锁不能阻止其他事务的插入操作，这就会导致幻读问题，这种情况下，我们可以把锁加到表上或者使用范围锁(间隙锁)。

通过对锁的类型（读锁还是写锁），锁的粒度（行锁还是表锁），持有锁的时间（临时锁还是持续锁）合理的进行组合，就可以实现四种不同的隔离级别.这四种不同的加锁策略实际上又称为 封锁协议（Locking Protocol）

Spring事务隔离级别

• ISOLATION_DEFAULT这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。另外四个与JDBC的隔离级别相对应 。默认采用的是重复读,除了insert幻读外基本的场景都能cover
• ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读
• ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。
• ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
• ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。

Spring事务传播级别

• PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。
• PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。
• PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。
• PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。当数据库分库分表存在跨库的时候需要启用
• PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。
• PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常。
• PROPAGATION_NESTED 如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。
  demo如下

      <!--事务模板 -->  
    <bean id="transactionTemplate"  
        class="org.springframework.transaction.support.TransactionTemplate">  
        <property name="transactionManager">  
            <ref local="transactionManager" />  
        </property>  
        <!--ISOLATION_DEFAULT 表示由使用的数据库决定  -->  
        <property name="isolationLevelName" value="ISOLATION_DEFAULT"/>  
        <property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>  
    </bean>