双写模式介绍
双写概念——说白了就是“两边都写”
双写，字面意思很简单：应用程序在写入数据库时，同时往两个目标写——旧的源库和新的目标库。我经常用“双通道记账”来打比方：你做了笔收支，两个账本各记一次，后续对账时谁错了一目了然。
具体到技术实现，双写不是简单的两条 INSERT 语句。我个人习惯在业务代码里封装一个统一的写入接口，通过开关控制写往哪个库。要么同时写两个库，要么只写一边作为降级。你想想看，如果没有这层抽象，等迁移时再改业务代码，那风险就大了。
一点经验：双写不是“写两次”那么简单。数据格式、主键生成、事务边界都得统一。我曾经因为新旧库的主键生成策略不同，导致双写后两边的 ID 对不上，排查了一整天。
为什么需要双写——停机迁移太痛了
传统的迁移方式，说白了就是“停服割接”。选个凌晨把应用停掉，做全量数据导出、导入、校验，再切流量。我在刚做架构师那会儿，经常凌晨三、四点盯着迁移脚本跑。
问题在哪？
- 停机时间不可控：几十个 TB 的数据，导进去可能 10 个小时，万一中途失败还得从头再来。
- 回滚成本极高：切过去了发现新库性能不行，要回退？那又是新一轮全量。
- 业务压力大：每次迁移都要协调 DBA、运维、业务方，像打仗一样。
双写模式就解决了这个问题。它让你在迁移过程中，业务完全在线。一边写旧库保证稳定，一边写新库持续校验。何时切换、何时下线旧库，全由你掌控。
| 对比维度 | 传统停机迁移 | 双写迁移 |
|---|---|---|
| 停机时间 | 数小时到数天 | 分钟级（仅切换瞬间） |
| 数据校验 | 迁移后一次性校验 | 持续校验，边写边对账 |
| 回滚难度 | 极高，需重新全量导入 | 低，关闭双写开关即可 |
| 业务影响 | 完全停服 | 完全在线 |
避坑指南：双写不等于“零风险”。如果双写逻辑写错了（比如漏了一条 where 条件），两边数据可能自始至终都不同步。我曾经就因为一个 ORM 的乐观锁实现差异，导致双写时新旧库行记录版本不一致。所以一定要同步做实时校验。
双写的核心优势——不止是“写两份”
双写最大的价值，是把迁移从“一次性爆破”变成“持续可控的过程”。我总结几个核心优势，也是我在项目里最常用的说服业务方的点：
- 零停机切换：这个最直观。双写跑一段时间后，确认新库数据和旧库完全一致，把流量直接切到新库。整个过程业务无感知。
- 细粒度回滚：切换后发现新库响应慢了、查询超时？啥也不用改，把应用的双写开关关闭，流量仍然只走旧库。回滚只需要改一行配置。
- 持续数据校验：在双写阶段，可以设计对比任务，每分钟或每小时对两边关键表做 count、对某个字段做 checksum。差异早发现早修复。
- 性能先行验证：新库性能好不好？双写阶段可以观察到新库的写入延迟、资源消耗。心里有底了再切换。
- 逐步放量控制：我习惯的做法是：先切 5% 的流量到新库，观察半小时没问题再提高到 50%，最后全量。双写下的灰度切换非常丝滑。
一句话总结：双写不只是一个技术方案，更是一种迁移策略。它把“赌一把”变成了“逐步验证”。
下面这张图说明了我最常用的双写架构流程：
从图中你能看到，双写的核心就是路由层和校验模块。嗯，这里要注意：路由层写两边的事务必须保证要么都成功，要么都失败（用分布式事务或最终补偿）。实际项目中我推荐使用消息队列异步双写，牺牲一点实时性换吞吐和可靠性。
个人总结
双写模式不是银弹，但它确实为数据迁移提供了一条“可验证、可回滚、可灰度”的路。我参与过的几个核心金融系统迁移，都用的这套方案，最长一次跑了三个月的双写，每天自动对账，零事故切换。只要设计好补偿机制和降级策略，双写比你想象中稳得多。