整体概述：组提交(group commit)是MySQL处理日志的一种优化方式，主要为了解决写日志时频繁刷磁盘的问题。组提交伴随着MYSQL的发展不断优化，从最初只支持redo log 组提交，到目前5.6官方版本同时支持redo log 和binlog组提交。组提交的实现大大提高了mysql的事务处理性能

mysql5.6官方版本之前：

5.6之前只支持redo组提交，当开启了binlog，为了保证redo和binlog的一致性，使用了两阶段提交（先刷新redo，再刷新binlog,并且以binlog刷新成功与否来判断事务是否成功），为了保证binlog和commit的顺序一致，binlog使用了串行化的刷新，导致binlog无法组提交， 5.6优化了这个步骤，引入了队列，保证了binlog有顺序，进而binlog也可以组提交；

接下来重点说说一：redo 组提交，二：两阶段提交。三：5.6 binlog组提交；

一：redo 组提交

WAL(Write-Ahead-Logging)是实现事务持久性的一个常用技术，基本原理是在提交事务时，为了避免磁盘页面的随机写，只需要保证事务的redo log写入磁盘即可，这样可以通过redo log的顺序写代替页面的随机写，并且可以保证事务的持久性，提高了数据库系统的性能。虽然WAL使用顺序写替代了随机写，但是，每次事务提交，仍然需要有一次日志刷盘动作，受限于磁盘IO，这个操作仍然是事务并发的瓶颈。

redo组提交思想是，将多个事务redo log的刷盘动作合并，减少磁盘顺序写。Innodb的日志系统里面，每条redo log都有一个LSN(Log Sequence Number)，LSN是单调递增的。每个事务执行更新操作都会包含一条或多条redo log，各个事务将日志拷贝到log_sys_buffer时(log_sys_buffer 通过log_mutex保护)，都会获取当前最大的LSN，因此可以保证不同事务的LSN不会重复。那么假设三个事务Trx1,Trx2和Trx3的日志的最大LSN分别为LSN1,LSN2,LSN3(LSN1提交的基本流程如下：

1）获取 log_mutex

2）若flushed_to_disk_lsn>=lsn，表示日志已经被刷盘,跳转5

3）若 current_flush_lsn>=lsn，表示日志正在刷盘中，跳转5后进入等待状态

4）将小于LSN的日志刷盘(flush and sync)

5）退出log_mutex

备注：lsn表示事务的lsn，flushed_to_disk_lsn和current_flush_lsn分别表示已刷盘的LSN和正在刷盘的LSN。

redo log 组提交优化

我们知道，在开启binlog的情况下，prepare阶段，会对redo log进行一次刷盘操作(innodb_flush_log_at_trx_commit=1)，确保对data页和undo 页的更新已经刷新到磁盘；commit阶段，会进行刷binlog操作(sync_binlog=1),并且会对事务的undo log从prepare状态设置为提交状态(可清理状态)。通过两阶段提交方式(innodb_support_xa=1)，可以保证事务的binlog和redo log顺序一致。二阶段提交过程中，mysql_binlog作为协调者，各个存储引擎和mysql_binlog作为参与者。故障恢复时，扫描最后一个binlog文件(在flush阶段，判断binlog是否超过阀值，进行rotate binlog文件，rotate的binlog文件中对应的事务一定是已经提交的，处于prepared的事务的binlog还没有刷进来，因为还没进入ordered_commit函数)，提取其中的xid；重做检查点以后的redo日志，读取事务的undo段信息，搜集处于prepare阶段的事务链表，将事务的xid与binlog中的xid对比，若存在，则提交，否则就回滚。

通过上述的描述可知，每个事务提交时，都会触发一次redo flush动作，由于磁盘读写比较慢，因此很影响系统的吞吐量。淘宝童鞋做了一个优化，将prepare阶段的刷redo动作移到了commit(flush-sync-commit)的flush阶段之前，保证刷binlog之前，一定会刷redo。这样就不会违背原有的故障恢复逻辑。移到commit阶段的好处是，可以不用每个事务都刷盘，而是leader线程帮助刷一批redo。如何实现，很简单，因为log_sys->lsn始终保持了当前最大的lsn，只要我们刷redo刷到当前的log_sys->lsn，就一定能保证，将要刷binlog的事务redo日志一定已经落盘。通过延迟写redo方式，实现了redo log组提交的目的，而且减少了log_sys->mutex的竞争。目前这种策略已经被官方mysql5.7.6引入。

二：两阶段提交

在单机情况下，redo log组提交很好地解决了日志落盘问题，那么开启binlog后，binlog能否和redo log一样也开启组提交？首先开启binlog后，我们要解决的一个问题是，如何保证binlog和redo log的一致性。因为binlog是Master-Slave的桥梁，如果顺序不一致，意味着Master-Slave可能不一致。MYSQL通过两阶段提交很好地解决了这一问题。

Prepare阶段：innodb刷redo log，并将回滚段设置为Prepared状态，binlog不作任何操作；

commit阶段：innodb释放锁，释放回滚段，设置提交状态，binlog刷binlog日志。

出现异常，需要故障恢复时，若发现事务处于Prepare阶段，并且binlog存在则提交，否则回滚。通过两阶段提交，保证了redo log和binlog在任何情况下的一致性。

伴随着这个问题，我重点说下，MySQL innodb 引擎事务commit的过程：

MySQL为了保证master和slave的数据一致性，就必须保证binlog和InnoDB redo日志的一致性（因为备库通过二进制日志重放主库提交的事务，而主库binlog写入在commit之前，如果写完binlog主库crash，再次启动时会回滚事务。但此时从库已经执行，则会造成主备数据不一致）。所以在开启Binlog后，如何保证binlog和InnoDB redo日志的一致性呢？为此，MySQL引入二阶段提交（two phase commit or 2pc），MySQL内部会自动将普通事务当做一个XA事务（内部分布式事物）来处理：

MySQL通过两阶段提交(内部XA的两阶段提交)很好地解决了这一问题，两阶段提交关键在于保证redo刷盘之后才能写binloglog 文件;MySQL5.6以前，为了保证数据库上层二进制日志的写入顺序和InnoDB层的事务提交顺序一致，MySQL数据库内部使用了prepare_commit_mutex锁。但是持有这把锁之后，会导致组提交失败；

      回到上节的问题，开启binlog后，如何在保证redo log-binlog一致的基础上，实现组提交。因为这个问题，5.6以前，mysql在开启binlog的情况下，无法实现组提交，通过一个臭名昭著的prepare_commit_mutex，将binlog刷盘串行化，串行化的目的也仅仅是为了保证redo log-Binlog一致，但这种实现方式牺牲了性能。这个情况显然是不能容忍的，因此各个mysql分支，mariadb，facebook，perconal等相继出了补丁改进这一问题，mysql官方版本5.6也终于解决了这一问题。由于各个分支版本解决方法类似，我主要通过分析5.6的实现来说明实现方法。

     binlog组提交的基本思想是，引入队列机制保证innodb commit顺序与binlog落盘顺序一致，并将事务分组，组内的binlog刷盘动作交给一个事务进行，实现组提交目的。binlog提交将提交分为了3个阶段，FLUSH阶段，SYNC阶段和COMMIT阶段。每个阶段都有一个队列，每个队列有一个mutex保护，约定进入队列第一个线程为leader，其他线程为follower，所有事情交由leader去做，leader做完所有动作后，通知follower刷盘结束。

MySQL5.6之前的如下两个阶段：

第一阶段（准备阶段）：InnoDB prepare，持有prepare_commit_mutex，并且write/sync redo log； 将回滚段设置为Prepared状态，binlog不作任何操作；

第二个阶段（提交阶段）：Commit Phase 包含两步

1.write/sync Binlog（这里为了保证和redo的顺序一样只能串行化的刷新）；

2.InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex，释放回滚段，设置提交状态)；

以 binlog 的写入与否作为事务提交成功与否的标志，innodb commit标志并不是事务提交成功与否的标志。因为此时的事务崩溃恢复过程如下：

1.崩溃恢复时，扫描最后一个Binlog文件，提取其中的xid；

2.InnoDB维持了状态为Prepare的事务链表，将这些事务的xid和Binlog中记录的xid做比较，如果在Binlog中存在，则提交，否则回滚事务。

通过这种方式，可以让InnoDB redo 和Binlog中的事务状态保持一致。

在写入innodb commit标志时崩溃，则恢复时，会借助redo log 重新对commit标志进行写入；

在prepare阶段崩溃，则binlog中肯定没有这些xid,则借助undo 回滚；

在write/sync binlog阶段崩溃，也会借助undo回滚。

MySQL5.6之前在开启Binary log时使用prepare_commit_mutex和sync_log保证二进制日志和存储引擎顺序保持一致，prepare_commit_mutex的锁机制造成高并发提交事务的时候性能非常差而且二进制日志也无法group commit；

MySQL5.6以及之后版本中的实现方式，重点解决了binlog组提交的问题：

上面的事务的两阶段提交过程是5.6之前版本中的实现，有严重的缺陷。当sync_binlog=1时，很明显上述的第二阶段中的 write/sync binlog会成为瓶颈，而且还是持有全局大锁(prepare_commit_mutex: prepare 和 commit共用一把锁)，这会导致性能急剧下降。

解决办法就是MySQL5.6中的 binlog组提交。

binlog组提交的基本思想是，引入队列机制保证innodb commit顺序与binlog落盘顺序一致，并将事务分组，组内的binlog刷盘动作交给一个事务进行，实现组提交目的。

binlog提交将提交阶段分为了3个阶段，FLUSH阶段，SYNC阶段和COMMIT阶段。每个阶段都有一个队列，队列中的第一个事务称为leader，其他事务称为follower，leader控制着follower的行为。

MySQL5.6之后的MySQL innodb 引擎事务commit的过程：

第一阶段（准备阶段）：InnoDB prepare，持有prepare_commit_mutex，并且write/sync redo log； 将回滚段设置为Prepared状态，完成后就释放prepare_commit_mutex，binlog不作任何操作；

第二个阶段（提交阶段）：InnoDB 提交阶段发生变化了，将Commit阶段拆分成了三步，每个阶段的任务分配给一个专门的线程：

FLUSH 阶段

1) 持有Lock_log mutex [leader持有，follower等待]

2) 获取队列中的一组binlog(队列中的所有事务)

3) 将binlog buffer到I/O cache

4) 通知dump线程dump binlog

SYNC阶段

这个阶段和参数sync_binlog有关系，

1) 释放Lock_log mutex，持有Lock_sync mutex[leader持有，follower等待]

2) 将一组binlog 落盘(sync动作，最耗时，假设sync_binlog为1)。

COMMIT阶段（这里不用写redo log，在prepare阶段已写）

1) 释放Lock_sync mutex，持有Lock_commit mutex[leader持有，follower等待]

2) 遍历队列中的事务，逐一进行innodb commit

3) 释放Lock_commit mutex

4) 唤醒队列中等待的线程

总结起来就是 ：

FLUSH 阶段-----将binlog从binlog buffer到I/O cache刷新；

SYNC阶段-------将binlog从I/O cache到底层磁盘；

COMMIT阶段----innodb commit ，清除undo信息；

每个stage都有自己的队列。每个队列各自有mutex保护，队列之间是顺序的。只有flush完成后，才能进入到sync阶段的队列中；sync完成后，才能进入到commit阶段的队列中。但是，这三个阶段的作业是可以同时并发执行的，即当一组事务在进行commit阶段时，其他新事务可以进行flush阶段，实现了真正意义上的group commit。