总结下多线程复制的流程,有不对之处请老师指出:
双1,配置为logical_clock,假设有三个事务并发执行也已经执行完成(都处于prepare阶段)
1.三个事务把redo log从redo log buffer写到fs page cache中
2.把binlog_cache flush到binlog文件中,最先进入flush队列的为leader,
其它两个事务为follower.把组员编号以及组的编号写进binlog文件中(三个事务为同一组).
3.三个事务的redo log做fsync,binlog做fsync.
4.dump线程从binlog文件里把binlog event发送给从库
5.I/O线程接收到binlog event,写到relay log中
6.sql thread读取relay log,判断出这三个事务是处于同一个组,
则把这三个事务的event打包发送给三个空闲的worker线程(如果有)并执行。

配置为writeset的多线程复制流程:
1.三个事务把redo log从redo log buffer写到fs page cache中
2.把binlog_cache flush到binlog文件中,根据表名、主键和唯一键(如果有)生成hash值(writeset),保存到hash表中
判断这三个事务的writeset是否有冲突,如果没有冲突,则视为同组,如果有冲突,则视为不同组.
并把把组员编号以及组的编号写进binlog文件中
(不过一个组的事务个数也不是无限大,由参数binlog_transaction_dependency_history_size决定组内最多事务数)
3.然后做redo log和binlog的fsync
4.dump线程从binlog文件里把binlog event发送给从库
5.I/O线程接收到binlog event,写到relay log中
6.sql thread读取relay log,如果是同一个组的事务,则把事务分配到不同的worker线程去应用relay log.
不同组的事务,需要等到上一个组的事务全部执行完成,才能分配worker线程应用relay log.

老师我有几个问题想请教下:
1.在备库是单线程下,second_behind_master是通过计算T3-T1得到,
在多线程的情况下,是怎么计算出second_behind_master的值？用的是哪一个事务的时间戳?
2.多线程复制下,如果从库宕机了,是不是从库有一个记录表记录那些事务已经应用完成,
恢复的时候,只需要恢复未应用的事务.
3.binlog延迟sync的两个参数,是延迟已经flush未sync时间。意思是让事务组占用flush时间更长,
之后的事务有更多的时间,从binlog cache进入到flush队列,使得组员变多,起到从库并发的目的
因为我理解的是加入到组是在binlog cache flush到binlog文件之前做的,如果此时有事务正在flush,
未sync,则后面的事务必须等待。不知道理解得对不

学习完这篇写下自己的理解，老师有空帮忙看下哦，备库一般会延迟分钟级别，比如主库压力比较大的时候，备库有可能会延迟小时级别，为此mysql官方提供了多种多线程复制策略
1、5.6基于库的多线程复制策略，使用hash数据库名作为key，value为多少个事务修改此数据库，使用hash来分配多线程，如果一个新事务加入进来，如果有冲突的hash，分配给此线程，如果没有冲突分配给空闲的线程，感觉实现的思路使用队列+线程池，如果线程池中没有空闲的线程，就在队列中增加事务，如果队列满，分发器阻塞，不解析binlog，分发器是生产者，线程池是消费者，基于库的多线程复制有如下优点①构造 hash 值的时候很快，只需要库名；线程的hash项也很少②binlog不需要强制指定row，statement也可以拿到库名。缺点：①如果只有一个库单线程复制，可以将其热点表分布到多个库中（不推荐使用），如果多个库的热点程度不同也会使其单线程复制。
2、基于表的多线程复制（非官方，老师实现），hash数据库名+表名作为key，value为多少个事务修改此数据表，同一个事务的多张表，在同一个线程进行处理，防止违反原子性，优点对同一个库多个热点表可以同时复制，多表负载效果很好，如果碰到热点表，比如所有的更新事务都会涉及到某一个表的时候，会使用单线程复制。
3、基于行的多线程复制，key必须是“库名 + 表名 + 唯一键的值“也需考虑唯一主键，防止唯一主键冲突（cpu的多线程调度，顺序不固定），value为修改前后key的次数，约束①表必须有主键②不能有外键③binlog格式row（表复制也一样）缺点：①大事务耗cpu②hash项多。优化可以设置阈值，如果事务修改的行大于特定值，使用单线程复制（老师自己实现）。mysql官网基于行的多线程复制，表示的是对于事务涉及更新的每一行，计算出每一行的 hash保存在writeset中，优点，①是有mysql主库写入binlog中，不需要解析 binlog 内容（event 里的行数据），节省计算量②binlog格式没要求，可以使用statement③无需扫描整个事务的binlog省内存，mysql5.7.22的多线程复制实现方式。
4、mysql5.7的多线程复制实现方式，借助于处于redo prepare到commit状态下的事务可以并行，因为执行器找引擎拿数据时，事务如果锁冲突会阻塞，无法到写redo log这一步，可以使用binlog故意延迟fsync，防止频繁写磁盘操作，不会丢失数据（redo prepar+完整的binlog事务才能提交，否则回滚），使其在备库多线程复制，主备延迟低，，但是这样有一点不好，语句的响应时间变长，感觉mysql官网故意延迟redo的fsync，在binlog write的时候（因为事务的binlog要写完整，时间较长），使其能批量提交，减少iops，感觉很巧妙