MySQL主从复制延迟一直是人人皆知诟病，令DBA非常头疼却又无可奈何。我们知道，大多数主从延迟是由于从库应用binglog跟不上主库造成的，如何使binlog中的事务在从库得到高效地应用成为解决问题的关键。MySQL研发团队一直在孜孜不倦地寻找解决方案，直到MySQL8,终见成效！
MySQL5.6提出了基于database的多线程应用方案，即从库为一个schema开启一个应用线程，如果事务更新的不是同一个schema，那么它们在从库就可以被并发执行。这个方案很蹩脚，并没有改变多少现状，它对于单库单实例的应用没有任何帮助。及时多库单实例中，大量并发热点库的读写依然会有不小的延迟。
紧接着MySQL5.7推出了基于logical_clock的并发应用策略。这个方案的关键技术是binlog group commit. 不同会话在同一时间commit的事务，在binlog中进行了分组。同一个分组内的事务复制到从库后可以被并发应用。而且还给出了相关变量来控制分组的大小以增强从库的并发效果。这个方案还是很赞，极大地缓解了主从延迟现状。但它也存在一定的局限性。如从库的并发不可能超过主库的并发，如果主库是单线程，从库也只能是单线程应用，延迟还是会存在。
MySQL8中推出了并发应用的终极大招：基于写集依赖跟踪的多线程应用技术（Writeset-based Dependency Tracking Parallel Applying）， 它不再依赖于group commit, 它根据一个事务的写集（writeset）是否有交集 ,来决定是否可以并发执行。也就是说，如果两个事务的写集没有交集，说明它们没有修改相同的数据，因此它们是可以被并发执行。从库的并发不再受制于主库的并发，即使主库是单线程执行，事务复制到从库依然可以多线程并发应用。这使得从库的吞吐量大大提升。
MySQL8引入了新的变量binlog_transaction_dependency_tracking，它有三个值可以选：
- COMMIT_ORDER（默认）事务的依赖信息由master的commit timestamp产生。对于不产生写集的事务即使设置为WRITESET或WRITESET_SESSION，也会退化为COMMIT_ORDER。哪些事务无法产生写集呢？如更新没有主键的表，DDL，或者更新有外键约束的表是无写集产生的。
- WRITESET 事务的依赖关系由写集产生，任何事务更新的写集没有交集就可以并发。
- WRITESET_SESSION 它和WRITESET一样，只是同一个session内的事务不可并发。
需要注意的是，若使用WRITESET或WRITESET_SESSION，必须启用transaction_write_set_extraction（XXHASH64|MURMUR32），不然无法设置binlog_transaction_dependency_tracking的值为WRITESET或WRITESET_SESSION。同样如果binlog_transaction_dependency_tracking的值为WRITESET或WRITESET_SESSION，尝试关闭transaction_write_set_extraction会报错。
另外引用的一个相关变量是binlog_transaction_dependency_history_size，默认是25000. 它是写集跟踪历史的长度（行数），底层使用了一个map对象（Writeset_history）缓存在内存中。当一个事务修改了某行数据，会从这个缓存中寻找上一次修改这行数据的事务的sequence_no作为其commit_parent. 其定义如下rpl_trx_tracking.h 类Writeset_trx_dependency_tracker：
/*
Track the last transaction sequence number that changed each row
in the database, using row hashes from the writeset as the index.
*/
typedef std::map<uint64, int64> Writeset_history;
Writeset_history m_writeset_history;
我们再看下获取事务依赖关系底层的实现机制(rpl_trx_tracking.cc)：
/**
Get the dependencies in a transaction, the main entry point for the
dependency tracking work.
*/
void Transaction_dependency_tracker::get_dependency(THD *thd,
int64 &sequence_number,
int64 &commit_parent) {
//这俩个变量是传的引用，其值双向传递
sequence_number = commit_parent = 0;
//对这三种可选的类型，分别实现了三个类。
switch (m_opt_tracking_mode) {
case DEPENDENCY_TRACKING_COMMIT_ORDER:
//对于COMMIT_ORDER, 调用commit_order类中的get_dependency方法。
// sequence_number和commit_parent都是引用传递
m_commit_order.get_dependency(thd, sequence_number, commit_parent);
break;
case DEPENDENCY_TRACKING_WRITESET:
m_commit_order.get_dependency(thd, sequence_number, commit_parent);
//如果是writeset 则在commit_order基础上再次调用writeset做事务依赖处理，这会缩小last_committed的值，使并发范围增大。
//如果该事务没有写集，则什么也不做。事务的依赖关系取决于上面的commit_order
m_writeset.get_dependency(thd, sequence_number, commit_parent);
break;
case DEPENDENCY_TRACKING_WRITESET_SESSION:
m_commit_order.get_dependency(thd, sequence_number, commit_parent);
m_writeset.get_dependency(thd, sequence_number, commit_parent);
//如果是writeset session则在writeset的基础上，再次做事务依赖关系处理，把同一个sesssion事务可并发的情况处理掉。它会在wirteset的基础上降低并发。
m_writeset_session.get_dependency(thd, sequence_number, commit_parent);
break;
default:
DBUG_ASSERT(0); // blow up on debug
/*
Fallback to commit order on production builds.
*/
m_commit_order.get_dependency(thd, sequence_number, commit_parent);
}
}
上面代码片段中，关键部分我做了些汉语注释。这段代码写的很精妙。因为要实现对于不产生writeset的事务，使用commit_order来生成依赖信息，在三个case中，都首先调用了m_commit_order.get_dependency(thd, sequence_number, commit_parent)来生成一次依赖关系，然后再调用m_writeset.get_dependency，对上面的依赖关系试图修改，如果事务没有写集，则什么也不做，并不影响已经生成的依赖关系。
这个方法是比较底层的处理，其参数commit_parent就是上层的last_committed。 通过其调用逻辑可以推断其对master性能的影响。使用COMMIT_ORDER，性能最好，WRITESET次之，WRITESET_SESSION最差，具体性能差异，还需要压测对比。而slave的并发性能则是，使用 COMMIT_ORDER 最差，WRITESET_SESSION 次之，WRITESET最好。
使用WRITESET的问题是，同一个session执行的事务在从库也可并发执行，这可能会导致从库binlog中事务执行顺序和主库binlog不一致，但并不影响数据的一致性。如果严格要求事务的commit顺序，有两种方式可选：
- 使用WRITESET_SESSION，同一个session事务不可并发。但会导致master性能最差，因为事务依赖关系要算三次。
- 使用WRITESET+slave-preserve-commit-order,也可保证事务执行顺序与master一致。至于性能教WRITESET_SESSION孰优孰劣，需要压测对比。
我做了一个测试，设置binlog_transaction_dependency_tracking=WRITESET，然后使用单线程压测主库，查看其binglog的内容片段：
[mount@Mounts-Mac]~/blog:grep last_committed ~/tmp/bin2.sql | more
#180708 19:12:54 server id 2 end_log_pos 285 GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1531048374763124 immediate_commit_timestamp=1531048374807831 transaction_length=1692
#180708 19:12:54 server id 2 end_log_pos 1977 GTID last_committed=1 sequence_number=2 rbr_only=yes original_committed_timestamp=1531048374824216 immediate_commit_timestamp=1531048374825436 transaction_length=1692
#180708 19:12:54 server id 2 end_log_pos 3669 GTID last_committed=1 sequence_number=3 rbr_only=yes original_committed_timestamp=1531048374837375 immediate_commit_timestamp=1531048374838367 transaction_length=1692
#180708 19:12:54 server id 2 end_log_pos 5361 GTID last_committed=1 sequence_number=4 rbr_only=yes original_committed_timestamp=1531048374848781 immediate_commit_timestamp=1531048374850233 transaction_length=1692
#180708 19:12:54 server id 2 end_log_pos 7053 GTID last_committed=1 sequence_number=5 rbr_only=yes original_committed_timestamp=1531048374882084 immediate_commit_timestamp=1531048374886304 transaction_length=1692
#180708 19:12:54 server id 2 end_log_pos 8745 GTID last_committed=1 sequence_number=6 rbr_only=yes original_committed_timestamp=1531048374901144 immediate_commit_timestamp=1531048374902336 transaction_length=1692
...
#180708 19:13:04 server id 2 end_log_pos 803985 GTID last_committed=116 sequence_number=476 rbr_only=yes original_committed_timestamp=1531048384965998 immediate_commit_timestamp=1531048384968042 transaction_length=1692
#180708 19:13:04 server id 2 end_log_pos 805677 GTID last_committed=1 sequence_number=477 rbr_only=yes original_committed_timestamp=1531048384982869 immediate_commit_timestamp=1531048384985381 transaction_length=1692
我们可以看到有许多last_committed的值是相同的，这些是可以在从库并发执行的。而且last_committed不再是顺序递增。（注：last_committed就是底层的commit_parent。last_committed相同说明其共同依赖同一个事务）
到这里，基于写集依赖跟踪的多线程应用(Writeset-based Dependency Tracking Parallel Applying)技术的关键部分都说到了。这是一个令人振奋的新特性，它开拓了mysql史上前所未有的新局面，特别是结合Group Replication+Writeset-based MTS可将mysql的内置高可用演绎到极致。什么MHA,MMA,半同步等都将成为历史。还说什么呢，拥抱MySQL8吧 ！
参考资料：
WL#9556
