Innodb事务种类及实现

innodb事务可以分为以下几种：

1.扁平事务    2.带有保存点的扁平事务    3.链事务    4.嵌套事务   5.分布式事务

各自分别介绍：

1.扁平事务

  这是事务中最简单的一种，也是使用最广泛的一种。在扁平事务中，所有的操作都在同一层次，由begin work开头，由commit work或者rollback work结束，两者之间的操作是原子性的，要么都做，要么都不做。

  扁平事务使用最为频繁，但它有一个主要的限制就是不能提交或者回滚事务的某一部分，或者分步骤提交，如果事务出现失败，就会全部回滚，这在某种情况下是不合适的。比如下边这个例子：

  begin work

  1：科比坐飞机来杭州

 :2：从杭州坐机场大巴去西湖

  当执行到2的时候，失败了，其实这个时候最好的是回滚2，而让1正常提交（毕竟从美国飞过来耗时太久），但扁平事务会让1也会滚，那么科比又得重新坐飞机来杭州了，这个就绝对是不合适的。

2.带有保存点的扁平事务

  为了解决第一种事务的弊端，就出现了这种事务类型。它允许事务子啊执行过程中回滚到较早的状态，而不是全部回滚。通过在事务中嵌入保存点，当本次操作失败后，就可以选择性的回滚到最近的保存点出，从而避免过多的回滚。保存点在事务内部是单调递增的，这对事务的执行或者分布式的控制都有好处。

  但这种事务有一个限制就是，如果数据库奔溃了，那么所有的保存点都会消失，那么当事务恢复的时候，又得重新执行一遍。

3.链事务

  链事务就是为了解决上边提出的问题的，它可以看做是保存点扁平事务的变种。当当前事务提交的时候，要将必要的上下文隐式传递给下一个事务，当然，事务的提交和传递动作是一个原子操作，这样的话，当事务失败之后就一定能回滚到最近的事务。但有一个问题就是，链事务只能保存本事务的上一个事务状态，所以它只能回滚到最近的保存点，而带保存点的扁平化事务是可以回滚到任意的保存点的，这是由程序开发人员设置的，如当前事务失败，可以选择回滚到上一个事务，或者上上一个事务

4.嵌套事务

  嵌套事务由顶层事务和子事务构成，类似于树的结构，有以下几个特点：

  1.顶层事务负责逻辑管理，子事务负责具体的工作，如访问数据类之类的

  2.子事务可以提交，但真正提交要等到父事务提交，以此类推

  3.上层事务回滚后，子事务都会回滚

5.分布式事务

  是在分布式环境中运行扁平化事务，这个我们都了解，通常由application、transaction manager、resource manager构成 。我的理解是，application就是我们的应用， transaction manager就是类似于数据库中间件之类的，resource manager就是我们的数据坤，通常由application发出指令，transaction manager负责协调底下的各个resource manager，不管是二阶段提交，还是基于消息的最终一致性，都可以完成分布式事务，当然，前提是要开启innodb对分布式事务的支持。

6.事务的实现

  我们知道，数据库的隔离性是由锁实现的，事务则是由数据库的redo log和undo log实现的。

  redo log，重做日志，用来保证事务的原子性和持久性，undo log，回滚日志，用来保证事务的一致性。

  redo 和undo都可以看作是一种恢复操作，但是redo是用来恢复事务修改的页操作，而undo是回滚到某个特定的版本，两个记录的内容是不一样的，redo一般是物理日志，记录的是页的物理修改记录，undo是逻辑日志，根据每行的记录来进行记录。

 具体来说：

 1.事务提交的时候，必须先写日志，再commit，这才算事务成功。当然，日志的写入可以先写到缓冲文件中，然后每隔一段时间，再刷新到磁盘，这会大大提高事务的效率，但有一个缺点就是，如果数据库奔溃，可能会损失一部分数据

  2.如果事务正在读取的数据被更改了，可以读取该数据的undo文件，实现非锁定读，这个我们之前说过。

  最后，innodb有一个purge操作，它负责清理被delete和update的数据。这是一个线程，由于innodb不会在事务提交时立即处理数据，它支持mvcc，所以每隔一段时间，purge就会运行，查看数据库中的记录是否还有被使用，如果没有，就将其真正清除。

  其实慢慢会发现，innodb的设计真的是一环套一环，没有哪一环是多余的，精妙的设计，换来了高效和稳定，还需要我们慢慢去摸索！