并行复制框架介绍：如何实现数据库异步复制及处理冲突

在MySQL复制架构中，并行复制是提升从库性能的关键技术。

核心之处在于怎样去有效运用系统资源从而达成使储存于主库那经过变更的数据，能够依托最为高效的方法在储存数据的从库上进行回放。

图4所展现出来的并行复制架构，从根本上来说，是针对最开始的单线程的SQL线程予以模块化处理，除此之外加以引入协调线程以及工作线程池，通过这些举措去达成多维度并发。

切入点有着两个主要方向，这两个方向涉及到并行复制，一个方向是并行IO线程，另一个方向是并行SQL线程。

并行的 IO 线程，重点对日志的拉取以及写入进行了优化，它把以往传统那种单线程处理结构给拆分了，拆成了网络拉取这一个方面，还有日志写入这另一个独立线程，如此一来能够有效地减缓网络发生抖动时而产生的延迟。

然而，从性能收益的角度来看，并行SQL线程的优化空间更大。

这是由于，SQL线程肩负着重放过程里的解析任务，还有事务应用任务，以及存储引擎交互等关键计算任务，这些操作，要比单纯的IO读写，费时多得多。

于MySQL官方版本5.6里头，首先达成了基于库级别（DATABASE）的并行复制。

类似上文当中图4里面的情形那般，协调线程也就是Coordinator Thread，它作为分发的中心之处，承担着从Relay Log里读取事情的任务，并且依据事情所属于的数据库，把那些事情分发给指定的工作线程也即Worker Thread。

工作线程仅专注于执行任务，无需关心冲突检测。

这种架构，具备这样的逻辑，即只要确保，同一个在数据库范围之内的事务，是由同一个工作线程以串行方式执行，那么，那些不同的数据库，像是处于图5当中的DB1、DB2、DB3之间的事务，便能够在多个工作线程里进行并发执行，因而，能够大幅度提高从库的吞吐量。

但库级并行存在明显的天花板。

要是业务场景很是高度集中在单一数据库，就像订单库这种或者核心用户库的时候情形下，所有事务居然都是会落在单一一个工作线程之上，进而退化成串行执行状态。

为了将此一瓶颈予以解决，并行的粒度，需要朝着更深入的方向下沉，一直下沉至表这个级别，甚至是事务这个级别。

关于表级并行，其有这样的要求，那就是协调线程必须致使得以解析出事务所关联涵盖的对应的那张特定的表，以此去保证操作处于同一张表的事务呈现出串行的状态，然而针对不同表的事务来说，它们则是能够并行的。

事务级并行更为精细，要深入解析行级更改，确保操作同一行数据的事务严格依序执行，达成最大程度的并发。

随之而来的核心问题便是冲突处理。

如图5所引发的思索，并发尽管美妙，然而却必要构建于数据一致性的基础之上面呢。

在所存在的并行复制模型里头，协调运作的线程，于进行任务分发之外，更为关键又重要的职责所在便是保持事务执行时的具体顺序。

若是以库级并发当作例子，那么协调线程需要去维护一个哈希表，或者维护一个队列映射，以此来记录每一个工作线程当前正着手处理的数据库。

读取到新事务时，该事务牵涉的数据库当中，要是有这个数据库正在处被某个工作线程占用状，那么会有必须等待或者得将该事务放置于相应线程的队列里头的情况出现并执行。

对于表级并发而言，冲突检测的逻辑变得更为纷繁复杂，同时对于行级并发来说亦是如此，协调线程此时不得不追踪比之前更细粒度的锁资源现象，诸如像是对表锁或者行锁所进行的模拟那般情况，千方百计确保不会出现有任意两个并发的事务去修改处于同一种状态的资源。

这是否意味着并行粒度越细，性能就一定越好？

答案是否定的。

并行复制的性能提升存在边际效应。

粒度越细，协调线程所需的冲突检测开销就越大。

在那种极高并发的关于事务的场景状况时，倘若大量事务真的有集中去操作同为一行的数据情况存在，协调线程频繁进行的冲突检测行动以及串行化调度举措，反而极有可能会变成新出现的瓶颈问题那。

处于这种状况下，多数的时间之内，线程都是处于等待锁资源的状态之中，实际上所执行的效率，甚至还比不上简单的串行复制呢。

如此一来，于实际的数据库运维这个范畴里，并行复制的配置可不是一味地去追求那种细粒度的情况了。

需要根据业务模型动态调整：

场景为多租户以及多业务库的情况，首先被选择的是根据DATABASE确定的并行复制方式，在这种方式下，其冲突检测所产生的开销是最小的，在性能表现上所取得的效果是最为显著的。

关于单库大表热点更新的那种场景，是能够去思考考虑升级到基于LOGICAL_CLOCK（也就是说逻辑时钟，它是事务级别的那种）的并行复制的。

MySQL 5.7版本引入的逻辑时钟机制具备特性，该机制对于主库上并行提交的事务，能让其在从库上并行进行回放，5.7其依托于基于组提交（Group Commit）的原理，此原理能够自动识别不存在冲突的事务组，8.0版本同样引入了这一逻辑时钟机制。

关于性能调优的技巧是，对工作线程忙碌与空闲的状态予以监控，并且对线程需要等待的事件进行协调。

要是发觉协调线程的CPU使用率过高，这或许就表明冲突检测开销庞大，那就必得适度降低并行度，或者优化SQL逻辑，以此来削减热点冲突。

对于硬件性能的充分获取依靠精密规划运行的调度算法，在妥善维持ACID状态予以保障的情形下，并行复制的原本实质就是利用资源去交换时间。

从库级到行级的演进，是数据库技术对高并发场景的不断适应。

对于一个健壮的并行复制架构而言，它离不开对业务特征的深刻理解，并且也离不开对协调线程与工作线程之间微妙平衡的精准把握。