MySQL 组提交（group commit）

---

前言

• 操作系统使用页面缓存来填补内存和磁盘访问的差距
• 对磁盘文件的写入会先写入道页面缓存中
• 由操作系统来决定何时将修改过的脏页刷新到磁盘
• 确保修改已经持久化到磁盘，须调用fsync或者fdatasync
• 数据库在事务提交过程中调用fsync将数据持久化到磁盘，才满足ACID中的D（持久化）
• fsync是昂贵的操作，对于普通磁盘，每秒能完成几百次fsync
• MySQL中使用了两阶段提交协议，为了满足D(持久化) ，一次事务提交最多会导致3次fsync
• 提交的事务在存储引擎内部（redo log）中准备好，一次fsync；事务写入到binlog中并刷盘持久化，一次fsync；事务在存储引擎内部提交，一次fsync（可以省略，存储引擎准备好的事务可以通过binlog来恢复）

改进

• 为了提高单位时间内的事务提交数，必须减少事务提交过程中的fsync调用次数
• MySQL 从5.6版本开始引入group commit技术（MariaDB 5.3版本引入）
• 基本思想是多个并发提交的事务共用一次fsync操作来实现持久化
  group commit
  An InnoDB optimization that performs some low-level I/O operations (log write) once for a set of commit operations, rather than flushing and syncing separately for each commit

原理

• 多个并发需要提交的事务共享一次fsync操作来进行数据的持久化
• 将fsync操作的开销平摊到多个并发的事务上去
• group commit 不是在任何时候都能发挥作用，要有足够多并发的需要提交的事务

实现

• 多个并发提交的事务在写redo log或binlog前会被加入到一个队列中
• 队列头部的事务所在的线程称为leader线程，其它事务所在的线程称为follower线程
• leader线程负责为队列中所有的事务进行写binlog操作，此时，所有的follower线程处于等待状态
• 然后leader线程调用一次fsync操作，将binlog持久化
• 最后通知follower线程可以继续往下执行

参数

binlog_group_commit_sync_delay=N

定时发车，在等待N 微秒后，进行binlog刷盘操作

binlog_group_commit_sync_no_delay_count=N

人满发车，达到最大事务等待数量，开始binlog刷盘，忽略定时发车

注意

• 当binlog_group_commit_sync_delay=0时，binlog_group_commit_sync_no_delay_count参数设置无效，即没有定时发车情况下，人满发车也就没有了~_~

• 当sync_binlog=0或sync_binlog=1，在刷盘前，对每个binlog应用定时发车
• 当sync_binlog=N（N>1），在每N个binlog后应用定时发车
• 设置了定时发车增加了并发提交事务的数量，从而增加slave并行apply的速度（slave开启多线程复制）
• 定时发车增加了事务提交的延迟，在高并发情况下，延迟有可能增加争用从而减少吞吐量

• 定时发车有优点也有缺点，要更具业务负载持续优化来决定最佳设置

参考
binlog_group_commit_sync_delay
《Mariadb 原理与实现》
MySQL组提交