分库分表迁移中的双写如何设计？

简化版

双写迁移要有单一事实来源、幂等版本和对账闭环。常见顺序是旧库主写并异步复制新库，补齐存量后灰度读新，最终切主；不要让业务同步串行写两库后假定原子。

“分库分表迁移中的双写如何设计？”不能只给组件名，还要交代路由范围、数据一致性、失败恢复和成本上限。

详细版

1. 记录变更日志/Outbox。
2. 全量回填带水位。
3. 增量追平。
4. 影子读校验。
5. 灰度读新并可回退。
6. 切主后反向同步一段窗口。

关键风险包括：双写部分成功要重试而非覆盖新值；事件携带单调版本防乱序；删除用墓碑传播；切换点要冻结路由版本并可回滚。

数字化说明：回填 5000 万行、净迁移速度 5000 行/s，至少约 10000 秒即 2.78 小时；期间产生的增量必须按位点继续追平。

完整版教学

一、定义与边界

双写迁移要有单一事实来源、幂等版本和对账闭环。常见顺序是旧库主写并异步复制新库，补齐存量后灰度读新，最终切主；不要让业务同步串行写两库后假定原子。

对于“分库分表迁移中的双写如何设计？”，先区分逻辑表、物理分片和路由层。分片提升单节点容量上限，却把原本由单库提供的 Join、事务、排序和约束变成跨节点协调问题。

记忆钩子：理解“分库分表迁移中的双写如何设计？”时要记住，分库分表不是免费扩容；每减少一次单机压力，往往会增加一份路由、迁移或一致性成本。

二、核心执行流程

记录变更日志/Outbox，随后全量回填带水位。

1. 记录变更日志/Outbox
2. 全量回填带水位
3. 增量追平
4. 影子读校验
5. 灰度读新并可回退
6. 切主后反向同步一段窗口

在“分库分表迁移中的双写如何设计？”的链路中，先“增量追平”，再“影子读校验”，最后“灰度读新并可回退”。这些步骤描述的是正常执行顺序；异常恢复仍要依赖下一节的数据版本、幂等与对账机制。

三、数字算例

回填 5000 万行、净迁移速度 5000 行/s，至少约 10000 秒即 2.78 小时；期间产生的增量必须按位点继续追平。

该算例说明“分库分表迁移中的双写如何设计？”必须估算扇出数、扫描行数、写放大、迁移速度或最慢分片，而不能只看单个物理库的平均耗时。

四、方案取舍

分库分表迁移中的双写如何设计？的取舍维度	低协调方案	强能力方案	代价
路由	强制携带分片键	允许索引或广播	后者增加读放大
一致性	单分片事务	跨片协调或补偿	延迟、锁与状态机增加
查询	预计算或单片下推	在线跨片归并	受最慢分片和内存约束
变更	固定逻辑槽	在线迁移路由	需双写、校验和回滚

选择“分库分表迁移中的双写如何设计？”的实现时，应先把正确性红线写出来，再在延迟、吞吐和开发复杂度间取舍；不能用透明中间件掩盖物理事实。

五、故障边界与恢复

• 双写部分成功要重试而非覆盖新值。
• 事件携带单调版本防乱序。
• 删除用墓碑传播。
• 切换点要冻结路由版本并可回滚。

处理“分库分表迁移中的双写如何设计？”涉及的任务和写入时，应携带幂等键、数据版本或路由 epoch。超时只代表结果未知，恢复逻辑必须先查状态再决定重试、补偿或回滚。

六、监控与验收

• 监控 复制延迟。
• 监控 版本冲突。
• 监控 对账差异。
• 监控 回填水位。
• 监控 读新回退率。

验收“分库分表迁移中的双写如何设计？”时，既要验证正常数据，也要覆盖热点键、空结果、重复事件、单分片超时、迁移中断和版本回退，且对账差异必须为零或处在明确业务阈值内。

七、常见误区与追问

• 误区：同步双写自然原子。 两库仍可能一成一败。
• 误区：全量完成即可切流。 还要追平切点之后的增量。
• 误区：按更新时间能处理所有乱序。 时钟和乱序会覆盖新数据，应使用版本。
• 误区：删除无需迁移。 删除必须用墓碑同步。
• 误区：抽样一致就无需全量摘要。 抽样不能证明零差异。
• 追问：一个分片不可用时能否返回其余结果？ 只有业务明确接受部分结果并在响应中标记不完整时才可以，否则应失败而不是伪造全局正确。

八、加强记忆

回答“分库分表迁移中的双写如何设计？”可按“怎么路由 → 单片做什么 → 跨片如何归并 → 失败如何恢复 → 数据怎样对账”展开。

最终要让面试官听到具体边界：哪些查询保持单片、哪些能力被限制、最坏会扇出多少节点，以及扩容或故障时如何保证数据不重不漏。