Undo Redo log实现事务

数据库通常借助日志来实现事务，常见的有undo log、redo log，undo/redo log都能保证事务特性，undolog实现事务原子性，redolog实现事务的持久性。

undo log

Undo log 是为了实现事务的原子性。还用Undo Log来实现多版本并发控制(简称：MVCC)。

• 事务的原子性
  事务的所有操作，要么全部完成，要不都不做，不能只做一半。如果在执行的过程中发生了错误，要回到事务开始时的状态，所有的操作都要回滚。

• 原理
  Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

  假设有A、B两个数据，值分别为1,2。 进行+2的事务操作。
  A.事务开始.
  B.记录A=1到undo log.
  C.修改A=3.
  D.记录B=2到undo log.
  E.修改B=4.
  F.将undo log写到磁盘。
  G.将数据写到磁盘。
  H.事务提交
  这里有一个隐含的前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。

  之所以能同时保证原子性和持久化，是因为以下特点：
  A. 更新数据前记录Undo log。
  B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
  C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的,可以用来回滚事务。
  D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
  缺点：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。

Redo Log

• 原理
  和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。

• Undo + Redo事务的简化过程
  A.事务开始.
  B.记录A=1到undo log.
  C.修改A=3.
  D.记录A=3到redo log.
  E.记录B=2到undo log.
  F.修改B=4.
  G.记录B=4到redo log.
  H.将redo log写入磁盘。
  I.事务提交

总结

A-G的过程是在内存中进行的，相应的操作记录在redo log buffer（B&E），redo log buffer（E&G）中，事务执行结果（此时未提交）也存在db buffer中（C&F），buffer满了就写入磁盘当中，如果buffer存储的事务数量都是1个，也就意味着是将日志立即刷入磁盘，那么数据的一致性很好保证。如果存储多个的话，是一次事务完成就会先将redo log同步到磁盘当中并有一个状态位来记录是否提交，再去真正的提交事务，将db buffer 中的数据同步到DB的磁盘当中去。要保证在db buffer中的内容写入磁盘数据库文件之前，应当把log buffer的内容写入磁盘日志文件。这种方式可以减少磁盘IO，增加吞吐量。 不过，这种方式适用于一致性要求不高的情景。因为如果出现断电等系统故障，log buffer、db buffer中的完成的事务还没同步到磁盘会丢失。 像银行这种要求事务较高的一致性，就一定要保证每次事务都要记录到磁盘中，如果服务器down了的时候去redo log中恢复，重做一次已经提交的事务。

恢复(Recovery)

• 恢复策略
  前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的处理.有2中不同的恢复策略：

  A. 进行恢复时，只重做已经提交了的事务。（返回给客户端的是已经提交一定保证数据的可恢复持久性）
  B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务。比如在B-E过程中down机了，那么恢复时根据undo log去重新模拟当时的情景（但是如果log buffer的空间很大，log没有同步到磁盘这个过程就没有办法来进行，同时由于事务没有提交，返回给客户端的值是未提交成功，所以也没有关系）