🚀 AI篇持续更新中！（长期更新）
AI炼丹日志-31- 千呼万唤始出来 GPT-5 发布！“快的模型 + 深度思考模型 + 实时路由”，持续打造实用AI工具指南！📐🤖
💻 Java篇正式开启！（300篇）
目前2025年08月18日更新到：
Java-100 深入浅出 MySQL事务隔离级别：读未提交、已提交、可重复读与串行化
MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务正在更新！深入浅出助你打牢基础！
📊 大数据板块已完成多项干货更新（300篇）：
包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！
大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT案例 详解
并行复制技术详解
MySQL的主从复制延迟问题一直是数据库管理员和开发者关注的焦点。随着数据量增长和业务需求增加，传统的单线程复制模式已无法满足性能要求。MySQL从5.6版本开始引入并行复制功能，官方称为enhanced multi-threaded slave（简称MTS），旨在显著改善复制延迟问题。
传统复制架构的问题
在标准的主从复制架构中，从库主要依赖两个关键线程：
- IO Thread：负责从主库接收binlog事件并写入从库的中继日志（relay log）
- SQL Thread：负责从中继日志读取事件并在从库上执行
这两个线程都采用单线程工作模式，当主库写入量较大时，特别是涉及大量DML操作时，SQL Thread很容易成为瓶颈，导致从库复制延迟不断增加。
并行复制的演进
MySQL 5.6的初步实现
在5.6版本中，首次引入了基于schema的并行复制。其核心思想是：
- 不同schema的DML操作可以并行执行
- 配置参数
slave_parallel_workers设置工作线程数 - 主要适用场景：多个业务使用不同schema的情况
局限性：单schema内的操作仍然串行执行，对于单schema写入量大的场景改善有限。
MySQL 5.7的增强
5.7版本推出了基于逻辑时钟(logical timestamp)的并行复制：
- 引入
slave_parallel_type=LOGICAL_CLOCK配置 - 使用组提交(group commit)信息判断哪些事务可以并行
- 新增
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count参数控制主库组提交行为
优势：同一schema内的事务也可能并行执行，显著提升性能。
MySQL 8.0的优化
8.0版本进一步改进为基于写集合(writeset)的并行复制：
- 通过
binlog_transaction_dependency_tracking参数控制 - 可选用WRITESET或WRITESET_SESSION模式
- 自动识别无冲突事务实现更细粒度的并行
特点：无需依赖组提交，减少主库性能影响，并行度更高。
应用场景与配置建议
适用场景
- 主库写入压力大的OLTP系统
- 报表系统需要低延迟的实时数据
- 读写分离架构中的从库
配置建议
# MySQL 5.7+ 推荐配置
slave_parallel_workers=8 # 根据CPU核心数设置
slave_parallel_type=LOGICAL_CLOCK # 或WRITESET(8.0+)
binlog_group_commit_sync_delay=10000 # 微妙单位，适当增加可提升并行度
性能考量
实际测试表明，在适当配置下，并行复制可以：
- 减少60%-80%的复制延迟
- CPU利用率提升30%-50%
- 对网络带宽需求基本不变
但需要注意，过度增加工作线程数可能导致锁竞争加剧，反而降低性能。建议根据实际负载逐步调整测试。
5.6并行复制原理
MySQL 5.6版本引入的并行复制是基于库级别的并行执行机制，其核心思想是通过多线程方式来提升从库的复制效率。具体实现原理如下：
-
多库并行机制：
- 当主库上有多个数据库(database)时，从库会为每个数据库分配一个独立的工作线程
- 这些线程可以并行应用不同数据库的事务变更
- 例如，如果主库有db1、db2、db3三个库，从库可以创建三个线程分别处理这些库的binlog事件
-
实现特点：
- 事务在从库上的执行顺序与主库保持一致
- 同一个数据库的事务仍保持串行执行
- 不同数据库之间的事务可以并行执行
- 系统会自动维护事务间的依赖关系
-
适用场景：
- 多租户系统，每个租户使用独立的数据库
- 业务系统按功能模块拆分到不同数据库
- 数据仓库环境中存在多个独立数据集市
-
性能影响：
- 对于单库环境，该机制无法提供性能提升
- 数据库数量越多，并行效果越明显
- 建议配置slave_parallel_workers参数为数据库数量的1.5-2倍
-
配置方式：
-- 启用并行复制 SET GLOBAL slave_parallel_workers = 4; -- 设置并行模式为按库并行 SET GLOBAL slave_parallel_type = 'DATABASE'; -
局限性：
- 无法处理单个大库的性能瓶颈
- 跨库事务仍需要串行处理
- 对DDL操作的支持有限
这种并行复制机制虽然简单，但对于典型的Web应用架构(如每个客户一个独立数据库)能带来显著的复制性能提升，平均可以减少30%-50%的复制延迟。
基于从库的并行复制，实现相对简单，使用也相对简单些，基于库的并行复制遇到的单库多表使用的场景就发挥不出优势了，另外对事物并行处理执行顺序也是个大的问题。
5.7 并行复制原理
MySQL 5.7 版本实现了基于组提交(Group Commit)的并行复制机制，这是真正意义上的并行复制技术。与之前版本相比，5.7 的并行复制有以下重大改进：
工作原理
- 组提交机制：在 Master 端，同一个组提交的事务会被分配相同的 commit_id，这些事务在 Slave 端可以并行回放
- 二进制日志改进：binlog 中新增了 last_committed 和 sequence_number 字段，用于标识事务的并行关系
- 协调机制：Slave 的 SQL 线程会解析这些标识，将可以并行执行的事务分配给不同的 worker 线程
核心优势
- 保持执行顺序一致性：Slave 的回放顺序与 Master 完全一致，确保数据一致性
- 突破库级限制：不同于 5.6 版本的基于库的并行复制，5.7 可以在同一个库内实现并行复制
- 动态并行度：并行度可以根据系统负载动态调整，通过参数 slave_parallel_workers 控制
实际应用场景
- 高并发写入环境：当 Master 有大量并发写入时，Slave 可以保持接近实时的同步
- 大事务处理：多个大事务可以并行回放，显著提升复制效率
- 多表操作场景：即使操作同一个库的不同表，也能实现并行复制
性能对比
测试表明，在典型的 OLTP 场景下：
- 相比 5.6 版本，5.7 并行复制性能提升可达 5-10 倍
- 延迟时间减少 80% 以上
- 资源利用率更高，CPU 多核优势得以充分发挥
配置参数
关键的配置参数包括：
- slave_parallel_type = LOGICAL_CLOCK
- slave_parallel_workers = (建议设置为 CPU 核心数的 2-4 倍)
- slave_preserve_commit_order = ON (确保事务最终提交顺序)
这种基于组提交的并行复制机制，使得 MySQL 5.7 在主从复制性能上实现了质的飞跃，为高并发场景下的数据同步提供了可靠保障。
MySQL 5.7 组提交并行复制的实现机制
MySQL 5.7 的并行复制通过引入事务分组机制显著提升了复制性能，其核心实现原理如下：
1. 事务分组机制
- 主库处理：当多个事务同时进入提交阶段时，系统会将这些事务划分为一个组
- 二进制日志标记：在写入二进制日志时，会为同一组的事务添加特殊的组提交标记
- 组内事务特性：同一个组内的事务满足以下条件：
- 无锁冲突
- 不修改相同的数据行
- 可以安全地并行执行
2. 实现原理
- Prepare阶段检测：在事务prepare阶段，系统会检测事务间的冲突关系
- 并行提交判断：所有通过prepare阶段检测的事务即被视为可并行提交
- 二进制日志写入：将可并行的事务作为一个组整体写入二进制日志
3. 从库并行执行
- 组信息解析：从库通过解析二进制日志中的组提交信息识别可并行执行的事务组
- 并行回放：同一组内的事务由不同的工作线程并行执行
- 执行保障：系统确保组内事务不会：
- 产生数据冲突
- 造成死锁
- 违反事务隔离级别
4. 技术优势
相比传统复制方案，这种实现方式具有以下优势：
- 完全规避冲突检测：通过组提交机制从根本上避免冲突
- 简化并发控制：不再需要复杂的并发算法和等待策略
- 显著提升性能：并行度更高，资源利用率更好
5. 应用场景示例
- 电商系统的高并发订单处理
- 社交媒体的用户行为日志记录
- 金融系统的批量交易处理
这种创新的并行复制思路代表了MySQL复制技术的重大进步，为高并发场景提供了更高效的复制解决方案。
InnoDB 事务提交采用的是两阶段提交（2PC）模式，这是确保事务原子性和持久性的重要机制。具体过程分为两个阶段：
-
prepare 阶段：
- 事务写入 redo log（重做日志），标记为 prepare 状态
- 此时事务已经完成所有修改操作，但尚未最终确认提交
- InnoDB 会确保 redo log 持久化到磁盘
-
commit 阶段：
- 事务写入 binlog（二进制日志）
- 将 redo log 标记为 commit 状态
- 完成事务提交
在 MySQL 5.6 版本中，主从复制采用的是基于库（database）的并行复制方式，即不同库的事务可以在从库并行执行。这种方式的并行度取决于数据库实例中的库数量。
为了提升复制性能，MySQL 5.7 引入了新的变量 slave-parallel-type，该变量有以下两种配置值：
● DATABASE（默认值）：
- 保持与 5.6 版本相同的基于库的并行复制方式
- 适用于多库环境，如分库分表场景
- 示例：如果有 db1、db2、db3 三个库，这三个库的事务可以在从库并行执行
● LOGICAL_CLOCK：
- 基于组提交（group commit）的并行复制方式
- 能在单库场景下实现更高并行度
- 工作原理：识别主库上同时进入 prepare 阶段的事务，这些事务可以在从库并行执行
- 性能优势：在 OLTP 场景下，特别是单库高并发写入时，可以显著提升复制性能
实际应用中选择哪种模式需要考虑：
- 数据库架构（多库还是单库）
- 工作负载特性（OLTP 或 OLAP）
- 对复制延迟的敏感度
在 MySQL 5.7 及更高版本中，建议在高并发写入场景下使用 LOGICAL_CLOCK 模式以获得更好的复制性能。
那么如何知道事务是否在同一个组中呢？
在MySQL中判断事务是否属于同一个组提交组，主要通过以下机制实现：
- 组提交标识机制：
- 同一个组内的事务会共享相同的组提交标识
- 这个标识会被记录在事务的元数据中
- 系统通过比较这个标识来判断事务是否属于同一组
- 具体实现方式：
- 在准备阶段，协调线程会为同一批提交的事务分配相同的组ID
- 这个组ID会随着事务一起持久化到日志中
- 在恢复或复制时，通过读取这个组ID来判断事务的组关系
生成的Binlog如何告诉Slave哪些事务是可以并行复制的？
MySQL通过以下几种方式在Binlog中标记可并行复制的事务：
- GTID机制：
- 每个事务都会被分配一个全局唯一的事务标识(GTID)
- 相同组提交组内的事务会被分配连续的GTID序列
- Slave通过分析GTID序列来判断事务的并行关系
- 具体标记方式：
- 在Binlog事件头中设置特殊的标志位
- 使用特定的日志事件类型来标识组边界
- 在事务元数据中记录组提交信息
- 通信协议：
- Master会通过Binlog事件将组提交信息传递给Slave
- Slave端的并行复制线程会解析这些信息
- 根据解析结果决定如何并行应用这些事务
MySQL 5.7中的实现细节
在MySQL 5.7版本中，具体通过以下设计实现组提交信息的传递：
- GTID方案：
- 默认将组提交信息存放在GTID中
- 每个GTID包含：source_id:transaction_id
- 相同组提交的事务会有连续的transaction_id
- 匿名GTID方案：
- 为兼容未开启GTID的场景(GTID_MODE=OFF)
- 引入ANONYMOUS_GTID_LOG_EVENT事件类型
- 这种事件会包含类似于GTID的组提交信息
- 但不会暴露给用户可见的GTID标识
- 实现特点：
- 无论是否开启GTID都能支持组提交信息传递
- 保证向下兼容性
- 对用户透明，不需要额外配置
- 在Binlog中以二进制形式存储，不占用太多空间
- 典型应用场景：
- 主从复制环境
- 基于Binlog的恢复场景
- 数据库迁移过程
- 数据同步工具的数据获取
通过 mysqlbinlog 工具分析 binlog 日志，就可以发现组提交的内部信息：
我们可以发现 MySQL 5.7 二进制较之前原来的二进制聂荣多了 last_commited 和 sequence_number，last_committed表示事务提交的时候，上次事务提交的编号，如果事务具有相同的 last_commited，表示这些事务都在一组内，可以进行并行的回放。
8.0并行复制原理
MySQL8.0是基于 write-set的并行复制，MySQL 一个集合变量来存储事务修改的记录信息（主键哈希值），所有已经提交的事务所修改的主键值经过Hash后都会与那个变量的集合进行对比，来判断该行是否冲突，并以此来确定依赖关系，没有冲突即可并行。
这样的粒度，就到 row 级别了，此时判断的粒度更加精细，并行的速度会更快。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
