1.基本概念

• 原子性。

整个事务是不可分割的最小单位，事务中任何一个语句执行失败，所有已经执行成功的语句也要回滚，整个数据库状态要恢复到执行事务前到状态。

• 一致性。
  

事务将数据库从一种状态转变为下一种一致的状态。在事务的前后，数据库的完整性约束没有被破坏。（事务的acid不是完全正交的，尤其是一致性，可能跟原子性、隔离性都有一定关系，后面会看到）

• 持久性。
  

事务一旦提交，那么就是永久性的，不会因为宕机等故障导致数据丢失（外力影响不保证，比如磁盘损害）。持久性是保证了数据库的高可靠性（High Reliability），而不是高可用性(Hign Availability)。高可用性并不能通过事务来保证。

2.持久性的实现

MySQL的innoDB存储引擎，使用Redo log保证了事务的持久性。

当事务提交时，必须先将事务的所有日志写入日志文件进行持久化，就是我们常说的WAL（write ahead log）机制（这个技术是保障持久性的关键技术，在HBase中也扮演重要角色，有兴趣的同学可以参考我之前的HBase文章）。这样才能保证断电或宕机等情况发生后，已提交的事务不会丢失，这个能力称为 crash-safe。

下面深入聊一聊redo log的机制，给大家更深刻的理解。

Redo log包括两部分，重做日志缓冲（redo log buffer）和重做日志文件（redo log file），前者是易失的缓存，后者是持久化的文件。

举一个事务的例子：

• 步骤1:begin;
  
• 步骤2:insert into t1 …r
  
• 步骤3:insert into t2 …
  
• 步骤4:commit;
  

这个事务的写入过程实际拆解如下：

innodb缓冲池的概念本文就不展开说明了，以后有机会可以展开说一下。

重点关注在这个事务提交前，将 redo log 的写入拆成了两个步骤，prepare 和 commit，这就是"两阶段提交”。

为什么要采用两阶段提交呢？

实际上，两阶段提交是分布式系统常用的机制。MySQL使用了两阶段提交后，也是为了保证事务的持久性。Redo log 和bingo 有一个共同的数据字段，叫 XID,崩溃恢复的时候，会按顺序扫描 redo log。

• 假设在写入binlog前系统崩溃，那么数据库恢复后顺序扫描 redo log，碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务，而且binlog也没写入，所以事务就直接回滚了。
  
• 假设在写入binlog之后，事务提交前数据库崩溃，那么数据库恢复后顺序扫描 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保证数据不丢失。
  

这个事务要往两个表中插入记录，插入数据的过程中，生成的日志都得先写入redo log buffer ，等到commit的时候，才真正把日志写到 redo log 文件。（当然，这里不绝对，因为redo log buffer可能因为其他原因被迫刷新到redo log）。

而为了确保每次日志都能写入日志文件，在每次将重做日志缓冲 写入 重做日志文件 后，InnoDB存储引擎都需要调用一次fsync操作，确保写入了磁盘。

对于redo log的持久化，可以如下图所示。

1）先写入redo log buffer，在蓝色区域。

2）写入redo log file，但是还没有fsync，这时候是处于黄色的位置，处于系统缓存。

3）调用fsync，真正写入磁盘。

为了控制 redo log 的写入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，它有三种可能取值：

• 设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ;
  
• 设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘；
  
• 设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。
  

binlog的写入和redo log一样，也是包括bingo cache和bingo file，同样跟上面的三色层次类似（当然，binlog是server层的，不是存储引擎层的），包括log buffer、文件系统page cache、hard disk。

写入page cache 和 fsync到disk 的时机，是由参数 sync_binlog 控制的：

• sync_binlog=0 的时候，表示每次提交事务都只 写入文件系统的page cache，不 fsync；
  
• sync_binlog=1 的时候，表示每次提交事务都会执行 fsync；
  
• sync_binlog=N(N>1) 的时候，表示每次提交事务都写入文件系统的page cache，但累积 N 个事务后才 fsync。（如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志）
  

通常我们说 MySQL 的“双 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说，一个事务完整提交前，需要等待两次刷盘，一次是 redo log（prepare 阶段），一次是 binlog。

特别需要区分的是，redo log和binlog的不同。这也是经常在面试中可能会问到的两种日志的差异。

注意有这么几点不同：

• 产生位置不同。

redo log是innodb的存储引擎产生的，而binlog是数据库的server层实现的。换句话说，如果你使用MySQL，换其他存储引擎，那么可能没有redo log，但是还是会有binlog。

• 日志记录的内容形式不同。
  

binlog是一种逻辑日志，记录对应的SQL语句，而redo log记录了物理日志，是针对每个数据页的修改。

• 日志写入时间不同。
  

binlog只有在事务提交后完成一次写入，对于一个事物而言，在binlog中只有一条记录。而redo log在事务进行中不断被写入，而且是并发写入的，不是顺序写入的。

• 保存方式不同。
  

redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

3.原子性的实现

Undo log保证了事务的原子性。

在对数据库进行修改时，innoDB引擎除了会产生redo log，还会产生undo log。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败导致事务需要回滚，就利用undo log中的信息将数据回滚到修改之前的样子。

有人认为undo log是redo log的逆过程，其实是不对的。两个日志文件其实都能看作是一种对数据的恢复操作，redo log恢复事务导致的数据页的修改，而undo log能够恢复数据记录到某个特定的版本。

所以redo log是一种物理日志（数据页的修改），而undo log是一种逻辑日志（数据记录）。

undo log还要另外一个重要作用，就是用于mvcc中，进行多版本控制，也就是实现事务隔离性的基础，当用户读取一行记录时，如果这个记录已接被其他事务占用，那么当前事务就可以通过undo读取之前的行版本信息，用来实现非锁定读取，就是“快照读”。（事务隔离性的问题，可以看我上一篇文章 跟面试官侃半小时MySQL事务隔离性，从基本概念深入到实现 ）。

4.一致性的实现

就像一开始在定义的时候介绍的，事务的ACID性质不是完全正交的，尤其是一致性，我们可以认为原子性、持久性和隔离性都是为了实现事务的一致性。

当然，这里的一致性是指数据库层面的事务一致性。

如果说你在应用层面做一个操作，给转账者扣钱，没给接收者加钱，那么这个不一致跟事务的不一致是没有关系的，需要开发人员自己做业务逻辑一致性的保证。