ShardingSphere 实战与平滑扩容
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 27/49 篇 · 🚧 占位待学
上一篇：《跨分片难题：分页、聚合与跨库事务》
下一篇：《雪崩机理：一次超时如何拖死全链路》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.6
一、本文要解决的问题
分片方案怎么不停机上线？2 库跑三年不够了，怎么扩到 4 库？这是分库分表从 PPT 落到生产的最后一公里——迁移过程出问题，比不分库还惨。本篇把 ShardingSphere 落地与「成倍扩容」两套 runbook 走通。
二、知识点清单
- ShardingSphere-JDBC vs Proxy：客户端直连（性能好、语言绑定）vs 独立代理（语言无关、多一跳）
- 5.5.x 分片配置实战：数据源、分片规则（行表达式）、广播表、绑定表
- 不停机迁移四步：全量同步（双写开始）→ 增量追平 → 切读验证 → 切写，每步的验证点与回滚点
- 成倍扩容法：2 库 → 4 库，翻倍使每个旧库只拆一半数据到新库，路由规则从 %2 变 %4 的平滑切换
- 迁移期数据校验：全量 checksum、增量对账、抽样比对
三、动手实验（学习时必须真跑）
- Spring Boot 接入 ShardingSphere-JDBC 5.5.3，配「2 库 4 表」分片 + 广播表 + 绑定表，跑通增删改查
- 模拟迁移：旧单库 → 双写 → 数据同步工具追平 → 校验 → 切读，全流程演练
- 模拟扩容：2 库扩 4 库，验证成倍扩容时只迁移一半数据、切换期间读写正确
四、验收标准（全部通过才进入下一篇）
五、阶段验收（本篇是阶段 4收尾篇）
六、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。