什么是两阶段提交和组提交

本篇文章为大家展示了什么是两阶段提交和组提交，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

出于性能的考虑，事务在提交时为了保证数据安全，需要将redo和undo数据落盘，不用等待数据落盘。但是不仅要考虑innodn存储引擎层的redo数据，还要考虑数据库上层的binlog数据落盘，已经两个层面数据落盘的顺序问题。两阶段提交可以解决单个事务redo和binlog落盘顺序的问题。

两阶段提交（2PC）分为两个过程：

l  准备阶段（prepare phase）

生成xid信息，回滚段设置为prepare状态，并将redo落盘。

l  提交阶段（commit phase）

在binlog生成commit 的XID event，Binlog落盘，释放回滚段，释放锁。

两阶段提交的回滚：
       只写了redo，没落盘binlog，回滚。

落盘了redo，binlog落盘成功了，也有commit XID，自然是成功。

落盘了redo，binlog落盘成功了，没有commit XID，也认为事务已提交。

现在再来思考下一个问题，如果每个事物提交的时候，都要去将redo和binlog落盘，那么瓶颈就在落盘阶段被放大了。这个时候就要引入组提交。组提交使得redo和binlog落盘的时候可以批量落盘，多个事务的redo和binlog可以一次fsync操作完成数据落盘，减少了fsync函数的调用，提高了效率。同时innodb存储引擎层本身就支持组提交。

组提交之后，引入了另一个问题。数据库上层的binlog写入顺序和innodb层事务提交顺序无法保持一致。如果不保持一致，那么就会出现通过在线工具比如xtrabackup备份数据库搭建主从的时候，出现丢失事务的场景，比如下面：

      binlog提交顺序（T1,T2,T3），innodb commit顺序（T2,T3,T1），此时innodb检测到T3上下两层都已经提交，认为不再需要恢复，那么T1事务在备份的时候没有经历两阶段提交，T1的事务在备份的时候数据还是事务开始前的数据，从库又不再进行恢复，导致T1事务被丢弃。所以后来引进了prepare_commit_mutex,以串行的方式来保证顺序，但是这样会使组提交失效，所以后来提出了BLGC（binary log group commit）

该行为分为三个阶段

Flush阶段

内存中生成事务的二进制日志

Sync阶段

将内存中多个事务的二进制日志调用1次fsync刷盘

Commit阶段

二进制日志在内存中会有一个队列，队列第一个事务是leader，其他时follower，leader会根据顺序调用存储引擎层事务提交。Innodb本身就支持组提交。