- 二阶段提交介绍 -
2PC全称是Two-PhaseCommit,翻译过来是二阶段提交,是分布式事务XA规范(XA规范是X/Open DTP定义的交易中间件与数据库之间的接口规范)的实现思路,满足CAP理论的CP,是强一致性事务。
二阶段提交将分布式事务分成二个阶段,表决阶段(Commit-Request-Phase)和提交阶段(Commit Phase)。角色分为:
表决阶段:
提交阶段:
- 二阶段提交的应用 -
在分布式系统中,由于软件或者硬件的原因,导致两个进程之间的数据出现不一致问题。不一致问题的其中一个解决思路就是分布式事务,针对数据强一致性的需求场景,二阶段提交可以满足。
- MySQL中binlog和redo log的二阶段提交广义应用 -
MySQL的双日志(binlog 和 redo log)记录采用二阶段提交保证数据的强一致性。
binlog是由MySQL Server层记录,与任何存储引擎无关。binlog主要记录的是操作日志,有三种格式:Statement、Row、Mixedlevel。binlog的主要用途是故障恢复、主从同步。
redo log是由Innodb存储引擎记录,磁盘的最小单位是⻚,MySQL的记录是以⻚为单位存取的,redo log记录的是针对⻚上的修改日志。redo log的主要用途是进程崩溃恢复,主要用来恢复⻚上的数据。binlog无法修复⻚上的数据,所以redo log不能省掉。
如果不使用二阶段提交模式,会出现什么问题呢:MySQL为了保证事务持久性,采用的是WAL机制。正常情况下binlog和redo log中都有事务开始和结束标识。如果binlog和redo log都是直接同步写入磁盘方式,即write + fsync方式。事务执行期间,每次都要写一次磁盘,TPS非常低,所以数据库不会这么设计。binlog和redo log在事务执行期间只写内存,当前链接线程不会主动去刷新到磁盘。接收到commit请求之后,当前才将binlog和redo log刷新到磁盘。
综上所述,只有事务处于已提交状态的情况下,才会出现数据不一致问题。为了保证数据一致性。事务提交时,redo log和binlog的Commit操作需要在同一个事务里,由于binlog和redo log由不同的层记录,需要分布式事务,为了保证数据一致性,二阶段提交满足这样的需求场景。
如图,可以看到redo log的写入有两个阶段,Prepare阶段和Commit阶段,Connect Client扮演事务发起者(AP),MySQL Server扮演事务协调者(TM),binlog和 redo log扮演事务参与者(RM)。redo log和 binlog既然是在同一个事务里,需要有一个事务id标识,即binlog文件中的Xid。
我们再分析一下基于二阶段提交方式的故障恢复过程。如果写redo log 处于Prepare阶段,主节点宕机(图中的①)。此时redo log 和binlog 都没有Commit标识,master崩溃恢复的时候此时事务会回滚,binlog没有写入,不会传输给slave。所以master和slave数据是一致的。
如果写binlog成功,主节点宕机(图中的②)。master崩溃恢复的时候,先判断redo log的状态(redo log处于prepare阶段时就要写入磁盘,否则崩溃无法恢复),此时没有Commit标识,会通过Xid判断当前事务在binlog中的状态,此时redo log有Commit标识(COMMIT或Xid event),直接提交。binlog已经写入,数据已同步给slave。所以master和slave的数据是一致的。
- MySQL二阶段提交特殊性 -
表决阶段:
提交阶段:
设计优点
总结:该机制名字叫最末参与者优化。
- 作者介绍 -
李凯 架构师一枚,现就职于快乐茄(原茄子快传)。主持设计过广告系统DSP平台、IM产品、百亿级Push平台。研究方向是分布式场景下架构设计。