记录1：<trx1, insert...>

        记录2：<trx2, delete...>

        记录3：<trx3, update...>

        记录4：<trx1, update...>

        记录5：<trx3, insert...>

      2.undo log

        undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。

        以下是undo+redo事务的简化过程

        假设有2个数值，分别为A和B,值为1，2

        1. start transaction;

        2. 记录 A=1 到undo log;

        3. update A = 3；

        4. 记录 A=3 到redo log；

        5. 记录 B=2 到undo log；

        6. update B = 4；

        7. 记录B = 4 到redo log；

        8. 将redo log刷新到磁盘

        9. commit

        在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。

        所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。

分布式事务

        分布式事务的实现方式有很多，既可以采用innoDB提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下innoDB对分布式事务的支持。

        

 

        如图，mysql的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）。

        应用程序定义了事务的边界，指定需要做哪些事务；

        资源管理器提供了访问事务的方法，通常一个数据库就是一个资源管理器；

        事务管理器协调参与了全局事务中的各个事务。

        分布式事务采用两段式提交（two-phase commit）的方式。第一阶段所有的事务节点开始准备，告诉事务管理器ready。第二阶段事务管理器告诉每个节点是commit还是rollback。如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。

总结

        什么时候需要使用事务呢？我想，只要业务中需要满足ACID的场景，都需要事务的支持。尤其在订单系统、银行系统中，事务是不可或缺的。这篇文章主要介绍了事务的特性，以及mysql innoDB对事务的支持。事务相关的知识远不止文中所说，本文仅作抛砖引玉，不足之处还望读者多多见谅。

 

参考文献：

　《高性能mysql第三版》

　《mysql技术内幕 innoDB存储引擎》

 

作者：mayday芋头 出处：http://www.cnblogs.com/maypattis/ 本博客中未标明转载的文章归作者mayday芋头和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

 

 

漫谈MySql中的事务

标签：