面试官：如何设计一个Mysql的主备并行复制策略

图2 多线程模型

coordinator就是原来的sql_thread, 不过现在它只负责读取中转日志和分发事务。更新日志的变成了worker线程。参数slave_parallel_workers决定work线程的个数。

coordinator在分发的时候，需要满足以下这两个基本要求：

1. 不能造成更新覆盖。即，更新同一行的两个事务，必须被分发到同一个worker中。

2. 同一个事务不能被拆开，必须放到同一个worker中。

2 面试官：你会如何设计并行复制策略

================================================================================

2.1 按表分发策略

---

如果两个事务更新不同的表，它们就可以并行。因为可以保证两个worker不会更新同一行。

如果有跨表的事务，还是要把两张表放在一起考虑的。

图3 按表并行复制模型

每个 worker 线程对应一个 hash 表，用于保存当前正在这个 worker 的执行队列里的事务所涉及的表。hash表的key是库名.表名，value是一个数字，表示队列中有多少个事务修改这个表。

在有事务分配给 worker 时，事务里面涉及的表会被加到对应的 hash 表中。worker 执行完成后，这个表会被从hash表中去掉。

hash.table 1表示，现在 worker1 的待执行事务队列里，有4个事务涉及到 db1.t1 表，有1个事务涉及到 db2.t2 表；hash.table 2表示，现在worker2 中有一个事务会更新表 t3 的数据。

假设在图中的情况下，coordinator从中转日志中读入一个新事务T，修改的行涉及到表 t1 和 t3。

由于事务 T 中涉及修改表 t1，worker1 队列中有事务在修改表t1，事务 T 和队列中的某个事务要修改同一个表的数据，事务T 和 worker1 是冲突的。

按照这个逻辑，顺序判断事务 T 和每个 worker 队列的冲突关系，会发现事务 T 跟 worker2 也冲突。

事务 T 和多于1个 worker 冲突，coordinator线程进入等待。

每个 worker 继续执行，同时修改 hashtable。假设 hash.table 2里面涉及到修改表 t3 的事务先执行完成，就会从hash.table 2中把 db1.t3 这一项去掉。

这样 coordinator 会发现跟事务 T 冲突的只有worker1了，因此就把它分配给worker1。

---

每个事务在分发的时候，涉及到以下三种情况：

1. 如果跟所有 worker 都不冲突，coordinator 线程就会把这个事务分配给最空闲的 woker;

2. 如果跟多于一个worker冲突，coordinator线程就进入等待状态，直到和这个事务存在冲突关系的 worker 只剩下1个；

3. 如果只和一个 worker 冲突，coordinator 线程就会把这个事务分配给这个存在冲突关系的 worker。

这个按表分发的方案，在多个表负载均匀的场景里应用效果很好。但是，如果碰到热点表，比如所有的更新事务都会涉及到某一个表的时候，所有事务都会被分配到同一个worker中，就变成单线程复制了。

2.2 按行分发策略

---

按行复制的核心思路是：如果两个事务没有更新相同的行，它们在备库上可以并行执行。

这时判断一个事务T和worker是否冲突，用的就规则就不是修改同一个表，而是修改同一行。

按行复制和按表复制的数据结构差不多，也是为每个 worker 分配一个 hash 表。只是要实现按行分发，这时候的 key，就必须是库名+表名+唯一键的值。

但这个唯一键只有主键id还是不够的，我们还需要考虑表中除了主键，还有唯一索引的情况：

CREATE TABLE t1 (

id int(11) NOT NULL,

a int(11) DEFAULT NULL,

b int(11) DEFAULT NULL,

PRIMARY KEY (id),

UNIQUE KEY a (a)

) ENGINE=InnoDB;

insert into t1 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

假设要在主库执行这两个事务：

图4 唯一键冲突示例

这两个事务要更新的行的主键值不同，但是如果它们被分到不同的 worker，就有可能 session B 的语句先执行。这时候id=1的行的 a 的值还是 1，就会报唯一键冲突。

因此，基于行的策略，事务hash表中还需要考虑唯一键，即key应该是库名+表名+索引a的名字+a的值。

要在表 t1 上执行update t1 set a=1 where id=2语句，在binlog里面记录了数据修改前后各个字段的值。

因此，coordinator在解析这个语句的 binlog 的时候，这个事务的hash 表就有三项:

1. key=hash_func(db1+t1+“PRIMARY”+2), value=2 这里value=2是因为修改前后的行id值不变，出现了两次。

2. key=hash_func(db1+t1+“a”+2), value=1，表示会影响到这个表 a=2 的行。

3. key=hash_func(db1+t1+“a”+1), value=1，表示会影响到这个表 a=1 的行。

相比于按表并行分发策略，按行并行策略在决定线程分发的时候，需要消耗更多的计算资源。这两个方案其实都有一些约束条件：

1. 要能够从binlog里面解析出表名、主键值和唯一索引的值。即主库的binlog格式必须是row；

2. 表必须有主键；

3. 不能有外键。表上如果有外键，级联更新的行不会记录在binlog中，这样冲突检测就不准确。

按行分发策略的并行度更高，如果是要操作很多行的大事务的话，按行分发的策略有两个问题：

1. 耗费内存。比如一个语句要删除100万行数据，这时候hash表就要记录100万个项。

2. 耗费CPU。解析binlog，然后计算hash值。

所以在实现这个策略的时候会设置一个阈值，单个事务如果超过设置的行数阈值（比如，如果单个事务更新的行数超过10万行），就暂时退化为单线程模式，退化过程的逻辑：

1. coordinator 暂时 hold 住这个事务；

2. 等待所有worker都执行完成，变成空队列；

3. coordinator直接执行这个事务；

4. 恢复并行模式。

3 MySQL 5.6版本的并行复制策略

==================================================================================

MySQL5.6版本支持了并行复制，只是支持的粒度是按库并行。用于决定分发策略的hash表里，key就是数据库名。

如果在主库上有多个DB，并且各个DB的压力均衡，使用这个策略的效果会很好。

相比于按表和按行分发，这个策略有两个优势：

1. 构造hash值的时候很快，只需要库名；而且一个实例上DB数也不会很多，不会出现需要构造100万个项这种情况。

2. 不要求binlog的格式。因为statement格式的binlog也可以很容易拿到库名。

但如果主库上的表都放在同一个DB里面，这个策略就没有效果了；或者如果不同DB的热点不同，比如一个是业务逻辑库，一个是系统配置库，那也起不到并行的效果。

4 MariaDB的并行复制策略

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后

手绘了下图所示的kafka知识大纲流程图（xmind文件不能上传，导出图片展现），但都可提供源文件给每位爱学习的朋友

0767821383)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）
[外链图片转存中…(img-xCkST0d0-1710767821383)]

最后

手绘了下图所示的kafka知识大纲流程图（xmind文件不能上传，导出图片展现），但都可提供源文件给每位爱学习的朋友

[外链图片转存中…(img-URNfQj8M-1710767821383)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录