事务相关-2022.04.07 - 《每日 Java 面试题背诵》

一组对数据库的操作，把这一组看成一个再给你，要么全部成功，要么全部失败。

举个栗子，比如A向B转账，A账户的钱少了，B账户的钱就应该对应增加，这就转账成功了，如果A账户的钱少了，由于网络波动等因素转账失败了，B账户的钱没有增加，那么A账户就应该恢复成原先的状态

原子性：指的是一个事务应该是一个最小的无法分割的单元，不允许部分成功部分失败，只能同时成功，或者同时失败

持久性：一旦提交事务，那么数据就应该持久化，保证数据不会丢失

隔离性：两个事务修改同一个数据，必须按顺序执行，并且前一个事务如果未完成，那么中间状态对另一个事务不可见

一致性：要求任何写到数据库的数据都必须满足预先定义的规则，它基于其他三个特性实现的

通过undo log 保证事务的原子性，redo log保证事务的持久性

undo log是回滚日志，记录的是回滚需要的信息，redo log记录的是新数据的备份

当事务开始时，会先保存一个undo log，再执行修改，并保存一个redo log，最后再提交事务。如果系统崩溃数据保存失败了，可以根据redo log中的内容，从新恢复到最新状态，如果事务需要回滚，就根据undo log 回滚到之前的状态

脏读：事务A读到了事务B修改还未提交的数据

幻读，也叫虚读：事务A两次读取相同条件的数据，两次查询到的数据条数不一致，是由于事务B再这两次查询中插入或删除了数据造成的

不可重复读：事务A两次读取相同条件的数据，结果读取出不同的结果，是由于事务B再这两次查询中修改了数据造成的

第一类丢失更新：也叫回滚丢失，事务A和事务B更新同一条数据，事务B先完成了修改，此时事务A异常终止，回滚后造成事务B的更新也丢失了

第二类丢失更新：也叫覆盖丢失，事务A和事务B更新同一条数据，事务B先完成了修改，事务A再次修改并提交，把事务B提交的数据给覆盖了

读未提交：事务读不阻塞其他事务的读和写，事务写阻塞其他事务的写但不阻塞读，能解决第一类丢失更新的问题，

读已提交：事务读不会阻塞其他事务读和写，事务写会阻塞其他事务的读和写，能解决第一类丢失更新，脏读的问题

可重复读：事务读会阻塞其他事务的写但不阻塞读，事务写会阻塞其他事务读和写，能解决第一类丢失更新，脏读，不可重复读，第二类丢失更新问题

串行化：使用表级锁，让事务一个一个的按顺序执行，能解决以上所有并发安全问题

利用了undo log实现的

undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，就可以利用undo log中的信息将数据回滚到修改之前的样子

利用了redo log实现的

redo log记录的是新数据的备份，在事务提交前，需要将Redo Log持久化，当系统崩溃时，可以根据redo Log的内容，将所有数据恢复到最新的状态

假设有A=1，B=2，两个数据，现在有个事务把A修改为3，B修改为4，那么事务的执行流程：

当事务开始时，会首先记录A=1到undo log，记录A=3到redo log，和记录B=2到undo log，记录B=4到redo log，然后再将redo log写入磁盘，最终事务提交

第一类丢失更新：也叫回滚丢失，事务A和事务B更新同一条数据，事务B先完成了修改，此时事务A异常终止，回滚后造成事务B的更新也丢失了

第二类丢失更新：也叫覆盖丢失，事务A和事务B更新同一条数据，事务B先完成了修改，事务A再次修改并提交，把事务B提交的数据给覆盖了

SQL标准中的四种隔离级别，读未提交，读已提交，可重复读，串行化，都能解决第一类数据更新丢失问题

对于第二类丢失更新问题，可以使用悲观锁也就是串行化来解决，也可以使用乐观锁的方式，比如加一个版本号管理来解决

隔离的实现主要利用了读写锁和MVCC机制

读写锁，要求在每次读操作时需要获取一个共享锁，写操作时需要获取一个写锁。共享锁之间不会产生互斥，共享锁和写锁，写锁与写锁之间会产生互斥。当产生锁竞争时，需要等一个操作的锁释放，另一个操作才能获得锁

MVCC，多版本并发控制，它是在读取数据时通过一种类似快照的方式将数据保存下来，不同的事务看到的快照版本是不一样的，即使其他事务修改了数据，但是对本事务仍然是不可见的，它只会看到第一次查询到的数据

可重复读是只在事务开始的时候生成一个当前事务全局性的快照，而读提交则是每次执行语句的时候都重新生成一次快照