主从复制与高可用 · 复制原理

binlog 的多线程复制为什么会出现写入冲突？怎么避免？

Why do write conflicts occur in binlog multi-threaded replication, and how can they be avoided?

答案语言

考察要点

这道题面试官想看你是否深刻理解 MySQL 主从复制的瓶颈以及多线程复制（MTS）的演进历程。核心考察点在于：

问题根源：为什么单线程复制会成为瓶颈，以及为什么简单的并行化会破坏数据一致性。
解决方案：你是否清楚从 MySQL 5.6 到 8.0，为了在保证数据一致性的前提下实现并行复制，引入了哪些关键技术和策略，特别是 DATABASE、LOGICAL_CLOCK 和 WRITESET 这三种模式的原理和区别。
权衡与取舍：你是否能分析不同并行方案的优缺点和适用场景，体现出你在技术选型上的思考深度。

核心概念

要理解写入冲突，首先要明白主从复制的基本流程和多线程复制（Multi-Threaded Slave/Replica, MTS）的引入背景。

1. 单线程复制的瓶颈

在 MySQL 5.6 之前，从库的复制是单线程的。主库的 binlog dump 线程将 binlog 事件发送到从库，从库的 I/O 线程接收并写入 relay log，然后由一个单独的 SQL 线程按顺序读取 relay log 并重放（apply）事务。

mermaid

 1graph LR
 2    subgraph Master/Source
 3        A[Client Writes] --> B{InnoDB Engine};
 4        B --> C[Binlog];
 5    end
 6    subgraph Network
 7        C --> D[Binlog Dump Thread];
 8    end
 9    subgraph Replica/Slave
10        E[IO Thread] --> F[Relay Log];
11        F --> G[SQL Thread];
12        G --> H{Replica DB};
13    end
14    D --> E;

瓶颈：主库可以并发处理大量写入请求，但从库只有一个 SQL 线程来重放这些事务。当主库写入压力大时，从库的 SQL 线程处理速度跟不上 relay log 的写入速度，导致 Seconds_Behind_Master（复制延迟）越来越大。

2. 多线程复制（MTS）与冲突的产生

为了解决单线程瓶颈，MTS 引入了多个 Worker 线程来并行重放事务。协调器（Coordinator）线程负责读取 relay log 并将事务分发给 Worker 线程。

冲突的根源：主库上顺序提交的事务之间可能存在依赖关系。如果从库并行执行这些事务时打乱了顺序，就会导致数据不一致或执行报错。

数据示例： 假设主库上依次执行了两个事务：

T1: INSERT INTO products (id, stock) VALUES (101, 10);
T2: UPDATE products SET stock = stock - 1 WHERE id = 101;

在主库上，T1 先于 T2 提交，写入 binlog。

在从库上，如果 Coordinator 将 T1 分配给 Worker1，将 T2 分配给 Worker2：

场景	Worker1 执行	Worker2 执行	结果
正确顺序	T1 (`INSERT`)	T2 (`UPDATE`)	成功，`stock` 变为 9
错误顺序	T2 (`UPDATE`)	T1 (`INSERT`)	失败。Worker1 执行 T2 时，`id=101` 的记录不存在，导致更新 0 行或报错。

这就是典型的写入冲突。为了实现正确的并行复制，MySQL 必须有一种机制来识别哪些事务可以安全地并行执行，哪些必须串行执行。

3. 并行复制的策略演进

MySQL 提供了不同的策略来决定事务的分发粒度，以避免冲突。这通过参数 replica_parallel_type（5.7及之前为 slave_parallel_type）来控制。

策略一：`DATABASE` (MySQL 5.6)

这是最早的并行策略。协调器线程根据事务影响的数据库（Schema）来进行分发。只有当两个事务操作的是不同的数据库时，它们才可能被分发到不同的 Worker 线程并行执行。

优点：实现简单，对于多租户、每个租户一个独立数据库的场景效果较好。
缺点：如果业务压力集中在单一数据库上，所有事务都会被分发到同一个 Worker 线程，MTS 将退化为单线程，无法起到加速作用。

策略二：`LOGICAL_CLOCK` (MySQL 5.7)

此策略基于组提交（Group Commit）的原理。在主库上，为了提升性能，多个并发的客户端提交的事务可能会被组合在一起，一次性 fsync 到 binlog。MySQL 认为，能够在一起组提交的事务，它们之间是没有数据冲突的（因为它们在主库的 prepare 阶段没有相互锁等待）。

工作原理：
1. 主库在组提交时，会为同一组内的所有事务打上相同的逻辑时间戳（last_committed）。这个时间戳会记录在 binlog 中。
2. 从库的协调器线程读取到这个时间戳后，会将具有相同 last_committed 值的所有事务分发给不同的 Worker 线程并行执行。
3. 不同 last_committed 值的事务组之间必须串行执行，即前一组全部执行完毕后，后一组才能开始。

mermaid

 1sequenceDiagram
 2    participant M as Master
 3    participant R as Replica Coordinator
 4    participant W1 as Worker 1
 5    participant W2 as Worker 2
 6
 7    M->>M: Group Commit 1 (T1, T2, T3), last_committed=N
 8    M->>R: Binlog Events for T1, T2, T3 (all with LC=N)
 9    R->>W1: Dispatch T1
10    R->>W2: Dispatch T2
11    R->>W1: Dispatch T3 (W1 is free)
12    W1-->>R: T1 Done
13    W2-->>R: T2 Done
14    W1-->>R: T3 Done
15    R->>R: Wait for all LC=N tasks to finish
16
17    M->>M: Group Commit 2 (T4, T5), last_committed=N+1
18    M->>R: Binlog Events for T4, T5 (all with LC=N+1)
19    R->>W1: Dispatch T4
20    R->>W2: Dispatch T5

优点：相比 DATABASE 粒度更细，只要主库并发度高、组提交效果好，从库就能获得很好的并行加速。
缺点：它是一个乐观的假设。如果业务通过应用层逻辑保证事务顺序（例如先 INSERT 后 UPDATE），但这两个事务恰好在主库上被分到两个不同的组提交批次中，那么从库无法利用这个信息，依然可能存在延迟。

策略三：`WRITESET` (MySQL 8.0)

这是目前最精准的并行策略。它在事务执行时，为每个事务生成一个写集（writeset），即该事务修改的行的主键（或唯一键）的哈希值集合。

工作原理：
1. 主库上需要开启 binlog_transaction_dependency_tracking=WRITESET。事务提交时，MySQL 会计算其 writeset 并写入 binlog。
2. 从库的协调器线程在分发事务时，会检查待分发事务的 writeset 与正在被 Worker 执行的事务的 writeset 是否有交集。
3. 如果 writeset(T_new) ∩ writeset(T_running) == ∅，则 T_new 与 T_running 不冲突，可以并行执行。
4. 如果存在交集，则 T_new 必须等待所有与之冲突的事务执行完毕后才能被分发。
相关参数：
- 主库：transaction_write_set_extraction=XXHASH64 (开启写集提取并指定哈希算法)
- 从库：replica_parallel_type=WRITESET
优点：真正基于数据行级别的冲突检测，并行度最高，最能有效降低复制延迟。
缺点：主库需要额外计算和存储 writeset，会带来微小的性能开销（通常在 1-5% 之间）。

常见低分回答

回答过于笼统：“把从库的 slave_parallel_workers 调大就行了。” —— 这是最典型的低分回答。只知其然不知其所以然，没有提到并行策略 slave_parallel_type，更不理解冲突的根源和解决方案。
混淆版本和策略：“MySQL 5.7 用写集来做并行复制。” —— 错误。WRITESET 是 8.0 的特性，5.7 的增强是 LOGICAL_CLOCK。这表明候选人对技术演进的脉络不清晰。
忽略主库配置：“多线程复制是纯从库的配置，和主库没关系。” —— 错误。LOGICAL_CLOCK 和 WRITESET 都依赖主库在 binlog 中写入额外信息（逻辑时钟或写集），因此需要在主库上进行相应配置（如 binlog_format=ROW, binlog_transaction_dependency_tracking 等）。
对 LOGICAL_CLOCK 的误解：“LOGICAL_CLOCK 就是按时间戳顺序执行。” —— 不准确。它不是简单地按时间戳排序，而是将相同时间戳的事务视为一个可并行的“批次”，不同批次之间是串行的。

工程实践与优化

首选 WRITESET：在 MySQL 8.0 及以上版本，如果业务对主库性能开销不极端敏感，应优先使用 WRITESET 模式，因为它的并行效果最好。
开启 GTID：MTS 强烈建议与 GTID 一起使用 (gtid_mode=ON, enforce_gtid_consistency=ON)。GTID 使得故障转移和复制链路管理更加简单可靠，是现代化 MySQL 复制架构的标配。
合理设置 replica_parallel_workers：这个值不是越大越好。通常建议设置为从库服务器 CPU 核数的 1-2 倍。过多的 Worker 会导致线程上下文切换开销增大，以及对存储的 I/O 争抢。
监控 MTS 性能：
- 通过 SHOW REPLICA STATUS 查看 Replica_SQL_Running_State。如果显示 Waiting for worker threads to free pending events，可能意味着 Worker 处理不过来，或者事务分发存在瓶颈。
- 使用 Performance Schema 中的表来深入分析，如 performance_schema.replication_applier_status_by_coordinator 和 performance_schema.replication_applier_status_by_worker，可以查看每个 Worker 的状态、正在处理的事务等。
处理大事务：即使在 WRITESET 模式下，一个超大的事务（如删除或更新几百万行数据）仍然会长时间占用一个 Worker，并可能阻塞所有后续依赖它的事务，导致延迟峰值。工程上应避免大事务，通过 LIMIT 分批处理。

常见追问与延伸题目

追问：如果我用了 MySQL 8.0 的 WRITESET 模式，但复制延迟还是很严重，可能是什么原因？
- 回答要点 1 (热点行冲突)：业务逻辑中存在一个或少数几个“热点行”，绝大多数事务都更新这几行数据。由于 WRITESET 检测到所有这些事务的写集都有交集，它们被迫串行执行，导致 MTS 效果大打折扣。需要从业务层面或架构层面（如缓存、分片）解决热点问题。
- 回答要点 2 (单个大事务)：如上所述，一个巨大的事务会长时间阻塞一个 Worker，并成为后续事务的依赖屏障，导致所有事务都在等待它完成。需要通过 pt-query-digest 分析慢查询日志或 performance_schema 找到这个大事务，并进行拆分优化。
- 回答要点 3 (硬件瓶颈)：从库的硬件性能（特别是磁盘 I/O）跟不上并行回放的压力。多个 Worker 同时写盘，可能会达到磁盘的 IOPS 或吞吐量上限。可以通过 iostat 等工具排查，考虑升级磁盘（如 HDD 到 SSD）。
- 回答要点 4 (DDL 阻塞)：一个 DDL 操作（如 ALTER TABLE）会成为一个全局屏障。协调器会等待所有已分发的事务完成后，单线程执行该 DDL，然后再继续分发后续事务。频繁的 DDL 会严重影响并行效率。应使用 pt-online-schema-change 或 gh-ost 等工具进行在线 DDL。
追问：WRITESET 是如何处理范围更新（如 UPDATE ... WHERE id BETWEEN 1 AND 10000）和表锁的？
- 回答要点 1 (范围更新)：WRITESET 机制是在存储引擎层实现的。对于范围更新，InnoDB 会在执行阶段确定所有受影响行的主键，并将这些主键的哈希值都加入到事务的写集中。因此，即使是范围更新，冲突检测的逻辑依然是准确的。
- 回答要点 2 (表锁/DDL)：当一个事务包含 DDL 或显式锁定了整张表（如 LOCK TABLES），MySQL 会在 binlog 中将该事务标记为不可并行。从库的协调器识别到这个标记后，会将其作为一个“屏障”事件。它会等待所有在它之前的事务都执行完毕，然后单线程执行这个屏障事务，执行完毕后，再恢复并行的事务分发。
追问：除了 MySQL，像 PostgreSQL 或分布式数据库 TiDB 是如何解决类似问题的？
- 回答要点 1 (PostgreSQL)：PostgreSQL 的流复制（Streaming Replication）默认是物理复制，即直接传输 WAL (Write-Ahead Log) 记录并在备库上应用。这本质上是单线程的物理重放，非常高效但灵活性差。从 v10 开始引入的逻辑复制，允许按行级别的变更进行复制，但其并行应用能力在不断发展中，通常需要配置多个订阅（subscription）来手动实现并行，其内置的依赖追踪不如 MySQL WRITESET 自动化和精细。
- 回答要点 2 (TiDB)：TiDB 作为分布式数据库，其复制机制与 MySQL 主从复制完全不同。它基于 Raft 一致性协议。数据被切分成多个 Region，每个 Region 有一个独立的 Raft Group。写入操作通过 Raft 协议在多个副本（Replica）之间同步，本身就是高可用的。它不存在单点写入后异步复制到从库的概念，因此也就不存在 MySQL 这种“复制延迟”和“并行复制冲突”的问题。它的挑战在于跨 Region 事务的原子性和性能，通过 Percolator 分布式事务模型（基于 2PC）来解决。