{"name":"复制","id":"中间件-数据库-mysql-复制","content":"# MySQL 复制系统\n\n## 一、复制系统要解决的本质问题\n\n复制不是为了\"多一份数据\"，而是为了解决以下**系统性约束**：\n\n1. **状态扩散问题**：如何将一个节点上的数据变更，可靠地扩散到其他节点\n2. **读写压力分摊**：写集中、读扩散的资源不对称问题\n3. **故障与不确定性**：节点失效、网络抖动、进程崩溃\n4. **一致性与可用性的权衡**：CAP 不可兼得\n\n> 因此，复制系统的目标不是\"零延迟\"，而是：\n> **在可控成本下，提供可预期的一致性与可恢复能力**。\n\n---\n\n## 二、复制系统的通用抽象模型（原理层）\n\n任何数据库复制系统，都可以抽象为以下五个稳定模块：\n\n```\n数据变更捕获\n      ↓\n变更传输\n      ↓\n变更缓冲\n      ↓\n变更重放\n      ↓\n一致性约束与治理反馈\n```\n\n| 抽象模块  | 核心问题     | MySQL 实现        |\n| ----- | -------- | --------------- |\n| 变更捕获  | 如何感知状态变化 | binlog          |\n| 变更传输  | 如何可靠传递   | IO Thread       |\n| 变更缓冲  | 如何削峰填谷   | relay log       |\n| 变更重放  | 如何应用变更   | SQL / worker    |\n| 一致性约束 | 如何避免冲突   | GTID / writeset |\n\n> 该模型独立于 MySQL，适用于 PostgreSQL、Oracle、CDC、消息复制系统。\n\n---\n\n## 三、MySQL 主从复制机制（实现层）\n\n### 3.1 基本工作流\n\n* 主库将数据变更追加写入 **binlog**（顺序、追加）\n* 备库 IO 线程拉取 binlog 写入 **relay log**\n* SQL 线程从 relay log 中顺序重放事务\n\n该设计的核心思想是：\n\n> **获取（IO）与重放（SQL）解耦**，以提升系统鲁棒性\n\n代价是：\n\n* 主库可以并发提交\n* 备库默认串行重放 → **复制延迟是必然结果**\n\n---\n\n## 四、复制语义与一致性模型\n\n### 4.1 复制不是一致性保证\n\n| 复制语义  | 本质含义     | 风险   |\n| ----- | -------- | ---- |\n| 异步复制  | 主库提交即返回  | 数据丢失 |\n| 半同步复制 | 至少一个备库确认 | 写延迟  |\n| 同步复制  | 多副本同时提交  | 吞吐下降 |\n\nMySQL 的半同步复制，是在：\n\n* **性能** 与 **数据安全** 之间的工程折中\n\n---\n\n## 五、复制格式：描述\"变更\"还是\"结果\"\n\n| 模式        | 描述对象   | 本质      |\n| --------- | ------ | ------- |\n| Statement | 操作意图   | 可解释但不确定 |\n| Row       | 最终结果   | 确定但成本高  |\n| Mixed     | 风险感知切换 | 工程权衡    |\n\n> 从系统角度看：\n> Row 模式本质是 **事件溯源（Event Sourcing）** 的一种实现。\n\n---\n\n## 六、并行复制：吞吐优化的边界\n\n### 6.1 为什么并行受限\n\n并行复制必须满足两个不变约束：\n\n1. 同一行的更新不能并行（避免写覆盖）\n2. 一个事务不能被拆分\n\n这不是 MySQL 的限制，而是：\n\n> **状态机复制的一般性约束**\n\n### 6.2 MySQL 的并行策略\n\n* DATABASE：按库隔离（结构性并行）\n* LOGICAL_CLOCK：按事务依赖\n* WRITESET：按行级冲突检测\n\n本质是：\n\n> **通过冲突检测，最大化可并行子图**\n\n---\n\n## 七、复制拓扑：结构决定风险\n\n### 7.1 常见拓扑的系统含义\n\n| 拓扑   | 优点   | 隐含风险  |\n| ---- | ---- | ----- |\n| 一主多备 | 简单清晰 | 主库瓶颈  |\n| 级联复制 | 扩展读  | 延迟放大  |\n| 主主复制 | 高可用  | 冲突复杂度 |\n| 环形复制 | 去中心化 | 失控风险  |\n\n> 拓扑不是连线问题，而是 **因果链路设计问题**。\n\n---\n\n## 八、复制治理：控制论视角\n\n复制系统必须被\"调控\"，而不是\"放任\"。\n\n### 8.1 治理闭环模型\n\n1. **观测**：延迟、一致性、错误\n2. **判定**：是否可接受\n3. **干预**：限流、切换、重建\n4. **反馈**：参数与架构调整\n\n### 8.2 核心治理指标\n\n* Seconds_behind_master\n* GTID 差集\n* checksum 差异\n\n---\n\n## 九、主备切换：可靠性 vs 可用性\n\n两种本质策略：\n\n| 策略   | 优先级 | 代价  |\n| ---- | --- | --- |\n| 等待追平 | 一致性 | 停写  |\n| 直接切换 | 可用性 | 不一致 |\n\n这不是技术问题，而是：\n\n> **业务对 CAP 的选择**\n\nGTID 的价值在于：\n\n* 将\"位点推理\"升级为\"集合推理\"\n\n---\n\n## 十、读写分离：一致性外溢\n\n读写分离的复杂性，来自一个事实：\n\n> **复制延迟被暴露给了应用层**\n\n常见解决方案，本质都是：\n\n* 要么回退主库\n* 要么等待因果完成\n\n不存在\"银弹\"。\n\n---\n\n## 十一、认知总结（稳定结论）\n\n* 复制不是高可用方案，而是冗余基础设施\n* 延迟不是异常，而是复制的物理代价\n* 并行复制的上限由冲突决定\n* 拓扑设计决定系统风险形态\n* 治理能力决定复制系统是否可长期运行\n\n## 关联内容（自动生成）\n\n- [/中间件/数据库/redis/复制.md](/中间件/数据库/redis/复制.md) Redis复制机制与MySQL复制在实现原理和架构设计上有很多相似之处，都涉及主从同步、数据一致性保证等问题\n- [/中间件/数据库/数据库系统/事务管理/事务.md](/中间件/数据库/数据库系统/事务管理/事务.md) 事务管理与复制系统密切相关，特别是在一致性保证、并发控制和数据完整性方面\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 分布式系统理论是理解数据库复制的基础，涉及CAP定理、一致性模型、分区容忍性等核心概念\n- [/中间件/数据库/分布式数据库.md](/中间件/数据库/分布式数据库.md) 分布式数据库扩展了单机数据库复制的概念，涉及多节点一致性、分片策略和全局事务管理\n- [/软件工程/架构/系统设计/分布式/分布式事务.md](/软件工程/架构/系统设计/分布式/分布式事务.md) 分布式事务与数据库复制密切相关，都涉及跨节点数据一致性的挑战和解决方案\n- [/中间件/数据库/数据库优化.md](/中间件/数据库/数据库优化.md) 数据库复制是数据库优化的重要组成部分，特别是在高可用性、读写分离和负载均衡方面的应用\n- [/中间件/数据库/mysql/mysql.md](/中间件/数据库/mysql/mysql.md) MySQL整体架构和核心概念，为深入理解MySQL复制机制提供了必要的背景知识\n- [/中间件/数据库/redis/哨兵.md](/中间件/数据库/redis/哨兵.md) Redis哨兵系统与MySQL复制在高可用架构设计方面有相似之处，都涉及故障检测和自动切换机制\n- [/中间件/数据库/redis/集群.md](/中间件/数据库/redis/集群.md) Redis集群架构与MySQL复制在分布式数据管理和一致性保证方面有共通之处\n- [/软件工程/架构/系统设计/缓存.md](/软件工程/架构/系统设计/缓存.md) 缓存与数据库复制在系统架构中都起到数据分发和性能优化的作用，存在设计上的关联性\n","metadata":"tags: ['数据库', '分布式系统', '架构设计']","hasMoreCommit":false,"totalCommits":1,"commitList":[{"date":"2026-06-11T22:56:06+08:00","author":"MY","message":"feat(cache): 添加缓存装饰器自定义键支持并优化缓存策略","hash":"ceec5426ef50ec3fe0b850b4975a7e3c8a930927"}],"createTime":"2026-06-11T22:56:06+08:00"}