全网最全MySQL多线程复制原理，深入浅出的进军数据库开发

如上图图所示，last. committed有三个值，分别是0、1. 4,这就表示当前Binlog包括三个组。也就是说，last_committed中的每个值对应于一个组的编号。last_committed为4 (1) 的有三个事务，这三个事务在5.7版本中,就被定义为可以并行复制(提交)的,而sequence_number是顺序增长的，每一个事务对应一个序列号(sequence_number)。

另外，还有一个细节可能不太容易被发现，其实每一个组的last_committed 值，都是上一个组中事务的sequence_number 最大值，也是本组中事务sequence_number 最小值减1。同时这两个值的有效作用域都在文件内，只要换一个文件(Aush binary logs)，这两个值就都会从0开始计数。

那么此时，还有一个很重要的技术问题一MySQL是如何做到将这些事务分组的呢?要搞清楚这个问题，首先需要了解一下MySQL的提交方式——ordered_commit。

int MYSQL_ BIN_LOG: ：ordered_ commit(THD *thd, bool all, bool skip_commit)

先看他的逻辑图，如下图所示

从上图中可以看到，只要事务提交(调用ordered. commit)，就都会先加入队列中。而提交有三个步骤，包括FLUSH. SYNC及COMMIT,相应地也有三个队列。首先要加入的是FLUSH队列，如果某个事务加入时，队列还是空的，则这个事务就担任队长，来代表其他事务执行提交操作。而在其他事务继续加入时，就会发现此时队列已经不为空了，那么这些事务就会等待队长帮它们完成提交操作。

在上图中，事务2~6都是这种坐享其成之辈，事务1就是队长了。不过这里需要注意一点，不是说队长会一直等待要提交的事务不停地加入，而是有一个时限，只有在这个时限之内成功加入到队列的，才能帮它提交。这个时限就是从队长加入开始，到它去处理队列的时间，这个时间实际上非常小，基本上就是程序从这行到那行的一个过程，也没有刻意去等待。只要队长将这个队列中的事务取出，其他事务就可以加入这个队列了。第一个加入的还是队长，但此时必须要等待。因为此时有事务正在做FLUSH,做完FLUSH之后，其他的队长才能带着队员做FLUSH。而在同-个时刻，只能有一个组在做FLUSH。这就是上图中所示的等待事务组2和等待事务组3，此时队长会按照顺序依次做FLUSH，做FLUSH的过程中，有一些很重要的事务需要去做，如下。

• 要保证顺序必须是提交加入到队列的顺序。

• 如果有新的事务提交，此时队列为空，则可以加入到FLUSH队列中。不过，因为此时FLUSH临界区正在被占用，所以新事务组必须要等待。

• 给每一个事务分配sequence_ number, 如果是第一个事务，则将这个组的last_committed设置为sequence_number-1。

• 将带着last_committed 与