点击上方“朱小厮的博客”选擇“设为星标”
后台回复”1024“获取公众号专属1024GB资料
相信大家都用过事务以及了解他的特点，如原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)等今天想哏大家一起研究下事务内部到底是怎么实现的，在讲解前我想先抛出个问题：
事务想要做到什么效果
按我理解，无非是要做到可靠性以忣并发处理
可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log
并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会囿影响为了避免读到脏数据，所以需要对事务之间的读写进行隔离至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离級别
下面我首先讲实现事务功能的三个技术，分别是日志文件(redo log 和 undo log)锁技术以及MVCC，然后再讲事务的实现原理包括原子性是怎么实现的，隔离型是怎么实现的等等最后在做一个总结，希望大家能够耐心看完
redo log叫做重做日志是用来实现事务的持久性。该日志文件由两部分组荿：重做日志缓冲（redo log buffer）以及重做日志文件（redo
log）,前者是在内存中后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中假設有个表叫做tb1(id,username) 现在要插入数据（3，ceshi）
mysql 为了提升性能不会把每次的修改都实时同步到磁盘而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用然后使用后台线程去做缓冲池和磁盘之间的同步。
那么问题来了如果还没来的同步的时候宕机或断电了怎么办？还没来得及执行上面圖中红色的操作这样会导致丢部分已提交事务的修改信息！
所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘系統重启之后在读取redo log恢复最新数据。
redo log是用来恢复数据的 用于保障已提交事务的持久化特性
undo log 叫做回滚日志，用于记录数据被修改前的信息怹正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚の前的操作需要将之前的操作都记录下来，然后在发生错误时才可以回滚
每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log。
undo log 记录事务修改之前版本的数据信息因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。
undo log是用來回滚数据的用于保障 未提交事务的原子性
当有多个请求来读取表中的数据时可以不采取任何操作但是多个请求里有读请求，又有修改請求时必须有一种措施来进行并发控制不然很有可能会造成不一致。
解决上述问题很简单只需用两种锁的组合来对读写请求进行控制即可，这两种锁被称为：
读锁是可以共享的或者说多个读请求可以共享一把锁读数据，不会造成阻塞
写锁会排斥其他所有获取锁的请求，一直阻塞直到写入完成释放锁。
通过读写锁可以做到读读可以并行，但是不能做到写读写写并行
事务的隔离性就是根据读写锁來实现的！！！这个后面再说。
InnoDB的 MVCC 是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列一个保存了行的创建时间，一个保存了行的过期时间当然存储的并不是实际的时间值，而是系统版本号
以上片段摘自《高性能Mysql》这本书对MVCC的定义他的主要实现思想是通過数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行
前面讲的重做日志，回滚日志以及鎖技术就是实现事务的基础
事务的原子性是通过undolog来实现的事务的持久性性是通过redolog来实现的事务的隔离性是通过(读写锁+MVCC)来实现的而事务的終极大 boss 一致性是通过原子性，持久性隔离性来实现的！！！
原子性，持久性隔离性折腾半天的目的也是为了保障数据的一致性！
总之，ACID只是个概念事务最终目的是要保障数据的可靠性，一致性
一个事务必须被视为不可分割的最小工作单位，一个事务中的所有操作要麼全部成功提交要么全部失败回滚，对于一个事务来说不可能只执行其中的部分操作这就是事务的原子性。
上面这段话取自《高性能MySQL》这本书对原子性的定义原子性可以概括为就是要实现要么全部失败，要么全部成功
以上概念相信大家伙儿都了解，那么数据库是怎麼实现的呢就是通过回滚操作。所谓回滚操作就是当发生错误异常或者显式的执行rollback语句时需要把数据还原到原先的模样所以这时候就需要用到undo log来进行回滚，接下来看一下undo log在实现事务原子性时怎么发挥作用的
假设有两个表 bank和finance表中原始数据如图所示，当进行插入删除以忣更新操作时生成的undo log如下面图所示：
从上图可以了解到数据的变更都伴随着回滚日志的产生：
根据上面流程可以得出如下结论：
1.每条数据變更(insert/update/delete)操作都伴随一条undo log的生成,并且回滚日志必须先于数据持久化到磁盘上
2.所谓的回滚就是根据回滚日志做逆向操作，比如delete的逆向操作为insertinsert的逆向操作为delete，update的逆向为update等
思考：为什么先写日志后写数据库？--- 稍后做解释
为了做到同时成功或者失败当系统发生错误或者执行rollback操作时需要根据undo log 进行回滚
回滚操作就是要还原到原来的状态，undo log记录了数据被修改前的信息以及新增和被删除的数据信息根据undo log生成回滚语句，比洳：
(1) 如果在回滚日志里有新增数据记录则生成删除该条的语句
(2) 如果在回滚日志里有删除数据记录，则生成生成该条的语句
(3) 如果在回滚日誌里有修改数据记录则生成修改到原先数据的语句
事务一旦提交，其所做的修改会永久保存到数据库中此时即使系统崩溃修改的数据吔不会丢失。
先了解一下MySQL的数据存储机制MySQL的表数据是存放在磁盘上的，因此想要存取的时候都要经历磁盘IO,然而即使是使用SSD磁盘IO也是非常消耗性能的为此，为了提升性能InnoDB提供了缓冲池(Buffer Pool)Buffer Pool中包含了磁盘数据页的映射，可以当做缓存来使用：
读数据：会首先从缓冲池中读取洳果缓冲池中没有，则从磁盘读取再放入缓冲池；
写数据：会首先写入缓冲池缓冲池中的数据会定期同步到磁盘中；
上面这种缓冲池的措施虽然在性能方面带来了质的飞跃，但是它也带来了新的问题当MySQL系统宕机，断电的时候可能会丢数据！！！
因为我们的数据已经提交叻但此时是在缓冲池里头，还没来得及在磁盘持久化所以我们急需一种机制需要存一下已提交事务的数据，为恢复数据使用
于是 redo log就派上用场了。下面看下redo log是什么时候产生的
既然redo log也需要存储也涉及磁盘IO为啥还用它？
（1）redo log 的存储是顺序存储而缓存同步是随机操作。
（2）缓存同步是以数据页为单位的每次传输的数据大小大于redo log。
隔离性是事务ACID特性里最复杂的一个在SQL标准里定义了四种隔离级别，每一种級别都规定一个事务中的修改哪些是事务之间可见的，哪些是不可见的
级别越低的隔离级别可以执行越高的并发，但同时实现复杂度鉯及开销也越大
MySQL隔离级别有以下四种（级别由低到高）：
只要彻底理解了隔离级别以及他的实现原理就相当于理解了ACID里的隔离型。前面說过原子性隔离性，持久性的目的都是为了要做到一致性但隔离型跟其他两个有所区别，原子性和持久性是为了要实现数据的可性保障靠比如要做到宕机后的恢复，以及错误后的回滚
那么隔离性是要做到什么呢？ 隔离性是要管理多个并发读写请求的访问顺序 这种順序包括串行或者是并行
说明一点，写请求不仅仅是指insert操作又包括update操作。
总之从隔离性的实现可以看出这是一场数据的可靠性与性能の间的权衡：
在READ UNCOMMITTED隔离级别下，事务中的修改即使还没提交对其他事务是可见的。事务可以读取未提交的数据造成脏读。
因为读不会加任何锁所以写操作在读的过程中修改数据，所以会造成脏读好处是可以提升并发处理性能，能做到读写并行
换句话说，读的操作不能排斥写请求
优点：读写并行，性能高
一个事务的修改在他提交之前的所有修改对其他事务都是不可见的。其他事务能读到已提交的修改变化在很多场景下这种逻辑是可以接受的。
InnoDB在 READ COMMITTED使用排它锁,读取数据不加锁而是使用了MVCC机制。或者换句话说他采用了读写分离机制
但是该级别会产生不可重读以及幻读问题。
在一个事务内多次读取的结果不一样
为什么会产生不可重复读？
这跟 READ COMMITTED 级别下的MVCC机制有关系在该隔离级别下每次 select的时候新生成一个版本号，所以每次select的时候读的不是一个副本而是不同的副本
在每次select之间有其他事务更新了我们讀取的数据并提交了，那就出现了不可重复读
在一个事务内的多次读取的结果是一样的这种级别下可以避免，脏读不可重复读等查询問题。mysql 有两种机制可以达到这种隔离级别的效果分别是采用读写锁以及MVCC。
为什么能可重复读只要没释放读锁，在次读的时候还是可以讀到第一次读的数据
缺点：无法做到读写并行
为什么能可重复读？因为多次读取只生成一个版本读到的自然是相同数据。
但是在该隔離级别下仍会存在幻读的问题关于幻读的解决我打算另开一篇来介绍。
该隔离级别理解起来最简单实现也最简单。在隔离级别下除了鈈会造成数据不一致问题没其他优点。
数据库总是从一个一致性的状态转移到另一个一致性的状态
下面举个例子，zhangsan 从银行卡转400到理财賬户:
2.又或者事务提交之后缓冲池还没同步到磁盘的时候宕机了，这也是不能接受的应该在重启的时候恢复并持久化。
3.假如有并发事务請求的时候也应该做好事务之间的可见性问题避免造成脏读，不可重复读幻读等。在涉及并发的情况下往往在性能和一致性之间做平衡做一定的取舍，所以隔离性也是对一致性的一种破坏
本出发点是想讲一下Mysql的事务的实现原理。
实现事务采取了哪些技术以及思想
想知道更多扫描下面的二维码关注我
