读写分离与主从复制：读扩展的第一刀
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 2 · 缓存体系 · 第 10/49 篇 · 🚧 占位待学
上一篇：《数据库为什么先死：读懂 MySQL 的极限》
下一篇：《缓存模式：谁来读写缓存，是一门学问》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.2
一、本文要解决的问题
读请求通常是写的十倍，而读天然可以复制——主从复制把读压力分给从库。但它引入一个新问题：复制是异步的，「刚写完马上读」可能读到旧数据。这个不一致窗口是读写分离全部方案的母题。
二、知识点清单
- 主从复制原理：主库 binlog dump 线程 → 从库 IO 线程写 relay log → SQL 线程重放
- 异步 / 半同步 / 全同步复制的取舍：RPO 与延迟的平衡
- 复制延迟的表现：用户改完头像看不到变化、下单后订单列表为空
- 读写路由的实现：动态数据源、ShardingSphere-JDBC 读写分离配置
- 强制走主的场景清单：写后立即读、金融对账、分页关键查询
- 一主多从的扩展边界：从库越多主库越累（复制风暴），引出级联复制与「读还是要缓存」
三、动手实验（学习时必须真跑）
- Docker Compose 搭 MySQL 一主两从（GTID 复制），造 10 万行数据验证同步
- 应用接入读写分离，压测读请求观察两从库的分担（连接数 / QPS）
- 在从库上执行一个大事务制造延迟，复现「主库已改、从库读到旧值」；再实现强制走主修复
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。