一、简单回顾三种日志

在讲解两阶段提交之前，需要对MySQL中的三种日志即binlog、redo log与undo log有一定的了解。

在这三种日志中，很多同学会把binlog与redo log混淆，下面使用一张表格来简单对比下两者的区别。

当然，如果对binlog与redo log有更深的兴趣，可以参考我的另外一篇文章数据库日志——binlog、redo log、undo log扫盲

这边只要记住两者的归属于适用场景即可，binlog适用于维护集群内数据的一致性，而redo log用于崩溃恢复。

undo log相对于前面两种日志更好理解些，就是为了回滚事务用的。

MVCC原理其实就是undo log版本链与ReadView的结合，想要弄清楚如何在快照读的情况下实现事务之间的隔离性，可以移步我的这篇文章通俗易懂的MySQL事务及MVCC原理，我先收藏了！

二、一条语句的执行过程

先从整体的角度来观测某件事物，可以避免一上来就陷入局部的泥潭当中。

MySQL分为Server层与存储引擎层，Server层包括连接器、分析器、优化器于执行器等。

而存储引擎层被设计为支持可插拔式，可以支持InnoDB、MyISAM等存储引擎。

一般来说，一条语句，不论是查询还更新，都会走以下的流程。

这部分不是本文的重点，就简单说下各个组件的作用，大家有个印象就行。

连接器

用于和客户端建立连接，管理连接。检查连接中的用户名密码是否正确吗，以及是否对表有操作权限。

分析器

只要是进行词法、语法分析，区分sql关键词与非关键词，生成一颗语法树。如果生成语法树失败，则证明你的sql有语法错误。

之后对语法树进行一些剪枝操作，去除一些无用的条件等。

优化器

生成sql的执行计划，你可以使用explain来查看执行计划。

会基于某些规则来选择走的索引项，在取样的时候可能会存在误差，可是使用force index来强制走某条索引。

执行器

依据执行计划，调用存储引擎的接口，来实现对数据的读写操作。

我们会在下一小节中，简单讲述执行器和存储引擎在两阶段提交中的交互流程。

三、两阶段提交

先看执行器与InnoDB引擎是如何更新一条指定的数据的：

可以看到，InnoDB在写redo log时，并不是一次性写完的，而有两个阶段，Prepare与Commit阶段，这就是"两阶段提交"的含义。

为什么要写redo log，不写redo log的话，根本就不会出现“两阶段提交”的麻烦事啊？

先说结论：在于崩溃恢复。

MySQL为了提升性能，引入了BufferPool缓冲池。查询数据时，先从BufferPool中查询，查询不到则从磁盘加载在BufferPool。

每次对数据的更新，也不总是实时刷新到磁盘，而是先同步到BufferPool中，涉及到的数据页就会变成脏页。

同时会启动后台线程，异步地将脏页刷新到磁盘中，来完成BufferPool与磁盘的数据同步。

如果在某个时间，MySQL突然崩溃，则内存中的BufferPool就会丢失，剩余未同步的数据就会直接消失。

虽然在更新BufferPool后，也写入了binlog中，但binlog并不具备crash-safe的能力。

因为崩溃可能发生在写binlog后，刷脏前。在主从同步的情况下，从节点会拿到多出来的一条binlog。

所以server层的binlog是不支持崩溃恢复的，只是支持误删数据恢复。InnoDB考虑到这一点，自己实现了redo log。

为什么要写两次redo log，写一次不行吗？

先不谈到底写几次redo log合适，如果只写一次redo log会有什么样的问题呢？

redo log与binlog都写一次的话，也就是存在以下两种情况：

先写binlog，再写redo log

当前事务提交后，写入binlog成功，之后主节点崩溃。在主节点重启后，由于没有写入redo log，因此不会恢复该条数据。

而从节点依据binlog在本地回放后，会相对于主节点多出来一条数据，从而产生主从不一致。

先写redo log，再写binlog

当前事务提交后，写入redo log成功，之后主节点崩溃。在主节点重启后，主节点利用redo log进行恢复，就会相对于从节点多出来一条数据，造成主从数据不一致。

因此，只写一次redo log与binlog，无法保证这两种日志在事务提交后的一致性。

也就是无法保证主节点崩溃恢复与从节点本地回放数据的一致性。

在两阶段提交的情况下，是怎么实现崩溃恢复的呢？

首先比较重要的一点是，在写入redo log时，会顺便记录XID，即当前事务id。在写入binlog时，也会写入XID。

如果在写入redo log之前崩溃，那么此时redo log与binlog中都没有，是一致的情况，崩溃也无所谓。

如果在写入redo log prepare阶段后立马崩溃，之后会在崩恢复时，由于redo log没有被标记为commit。于是拿着redo log中的XID去binlog中查找，此时肯定是找不到的，那么执行回滚操作。

如果在写入binlog后立马崩溃，在恢复时，由redo log中的XID可以找到对应的binlog，这个时候直接提交即可。

总的来说，在崩溃恢复后，只要redo log不是处于commit阶段，那么就拿着redo log中的XID去binlog中寻找，找得到就提交，否则就回滚。

在这样的机制下，两阶段提交能在崩溃恢复时，能够对提交中断的事务进行补偿，来确保redo log与binlog的数据一致性。

简单谈谈MySQL的两阶段提交相关推荐

mysql之两阶段提交
什么是两阶段提交当有数据修改时,会先将修改redo log cache和binlog cache然后在刷入到磁盘形成redo log file,当redo log file全都刷入到磁盘时(prep ...
mongodb mysql 事务_MongoDB数据库两阶段提交实现事务的方法详解 _ 蚂蚁视界
本文实例讲述了MongoDB数据库两阶段提交实现事务的办法.分享给年夜家供年夜家参考,详细如下: MongoDB数据库中操作单个文档老是原子性的,然而,涉及多个文档的操作,通常被作为一个"事 ...
mysql三阶段提交实现_基于两阶段提交的分布式事务实现(UP-2PC)
引言:分布式事务是分布式数据库的基础性功能,在2017年上海MySQL嘉年华(IMG)和中国数据库大会(DTCC2018)中作者都对银联UPSQL Proxy的分布式事务做了简要介绍,受限于交流形式难 ...
MySQL 为什么需要两阶段提交？
文章目录 1. 什么是两阶段提交 1.1 binlog 与 redolog binlog redo log 1.2 两阶段提交 2. 为什么需要两阶段提交 3. 小结为什么要两阶段提交?一阶段提交不 ...
提交mysql代码_MySQL源码之两阶段提交
在双1的情况下,两阶段提交的过程环境准备:mysql 5.5.18, innodb 1.1 version 配置: sync_binlog=1 innodb_flush_log_at_trx_com ...
mysql commit阶段,MySQL 基本架构与日志两阶段提交
MySQL大致可以分为Server层和存储引擎层 Server层包括连接器,查询缓存,解析器,预处理器,优化器,执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程,触发器和视图等连接器负责 ...
5.7之前的MySQL版本不完全支持两阶段提交
在对最近发布的通用JCA适配器进行一些测试时,该适配器能够将对微服务(以及其他东西)的远程调用绑定到JTA事务中,我发现Mysql 5.6中的一个错误已经存在了将近十年. 在XA事务的"准备 ...
MySQL调优（七）：滴滴一面二面题，服务器参数设置，redolog两阶段提交
某同学的滴滴一面二面 1.自我介绍不要念稿 2.对项目描述要准确,不要看起来不懂装懂:态度问题.一些问题没接触过很正常.不要所有问题都抢着说,要展示态度. 服务器参数设置 thread_cache_s ...
flink的mysql两阶段提交_flink 两阶段提交
flink exactly-once系列目录: 一.两阶段提交概述二.TwoPhaseCommitSinkFunction与FlinkKafkaProducer源码分析三.StreamingFil ...
分布式事务解决方案之2PC(两阶段提交)入门简介
什么是2PC? 2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Prepare phase).提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提 ...

简单谈谈MySQL的两阶段提交