本篇文章为大家展示了什么是两阶段提交和组提交，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
出于性能的考虑，事务在提交时为了保证数据安全，需要将redo和undo数据落盘，不用等待数据落盘。但是mysql不仅要考虑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本身就支持组提交。
上述内容就是什么是两阶段提交和组提交，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。
