上周帮一个老客户做系统升级，他们的订单库还是MySQL 5.6，跑了五年多，数据量已经快撑不住了。白天高峰期，几条慢查询就能把整个订单服务拖垮，运维小哥半夜爬起来清缓存已经是家常便饭。客户提了个需求：迁移到分布式数据库，但线上业务不能停，数据不能丢，接口响应时间还不能有明显波动。说白了，就是要在高速公路上换轮胎，而且轮胎还得是热乎的。
这事让我想起很多团队踩过的坑。有人直接停机迁移，被老板骂了个狗血淋头；有人用双写方案，结果数据对不上账；还有人搞了一大堆中间件，发现性能反而更差了。Java生态里数据库迁移的方案五花八门，但真正能落地、能平滑的，其实就那么几条路。
先说说最常见的双写方案。所谓双写，就是在业务代码里同时往老库和新库写数据，然后逐步切换读流量。听起来简单，但这里面的坑比想象中多得多。第一个坑是事务问题，你得保证老库和新库的写入要么都成功，要么都失败。Java里用Spring的话，本地事务好办，但跨库事务就得引入分布式事务框架，Seata也好，ShardingSphere也好，这套东西一上，性能损耗立竿见影。第二个坑是数据一致性校验，双写期间老库和新库的数据不可能完全一致，你得写脚本定期对账，发现差异还得回补，这个工程量一点都不小。
所以我的建议是，如果业务允许，先做存量数据迁移，再做增量同步，最后才切流量。存量迁移可以用工具，比如阿里开源的DataX，或者自研的批处理脚本。这里有个细节很多人忽略：迁移前一定要先做数据快照，快照时间点要记录清楚，不然增量同步的起点就乱了。Java里用JDBC批量插入的时候，要注意分批提交，别一口气几百万条塞进去，内存直接爆掉。我当时给客户做存量迁移，分了将近两百批，每批五万条，跑了大概四十多分钟，期间老库的写入和查询完全没受影响。
存量迁完之后，增量同步就成了重头戏。这时候需要借助binlog或者CDC工具，比如Canal、Debezium，它们能把老库的变更事件实时转发到新库。Java消费者这边要注意幂等性，因为消息中间件可能重复投递，你得在业务代码里做去重。我见过有人在这个环节偷懒，结果新库多了好几万条重复订单，对账的时候差点崩溃。另外，增量同步的延迟要做好监控，一旦超过阈值就得告警，不然切流量的时候才发现新库数据落后了一大截，那就麻烦了。
流量切换是整个迁移里最考验胆量的一步。很多团队喜欢一次性把所有流量切过去，万一新库有问题，整个业务就瘫了。我习惯的做法是灰度切换，先切百分之五的读流量，观察一段时间，没问题再加大比例。这里要配合Java里的配置中心，比如Apollo或者Nacos，把数据源路由规则做成动态配置，这样切流量的时候不用重新发版，改个配置就能生效。我当时给客户用的是Apollo，把路由规则从“全部走老库”改成“百分之五走新库”，保存发布后大概几秒钟就生效了，线上无感。
灰度期间要盯紧几个指标：接口响应时间、错误率、慢查询数量、数据一致性差异。一旦发现异常，立刻回滚配置，把流量切回老库。这里有个经验之谈：回滚的速度比切换的速度更重要，所以配置中心的操作路径一定要提前演练熟，别等出了事再翻文档找按钮。另外，灰度期间老库和新库的数据差异要持续对账，我一般会写一个定时任务，每小时跑一次，把差异数据拉出来人工review。
等灰度稳定了，比如连续跑了一周没问题，就可以考虑把写流量也切过去。但写流量切换前，一定要先停掉增量同步，确保新库数据完全追平老库。这一步很多人容易忘，结果切完写流量才发现新库还差着几分钟的数据，那几分钟的订单就丢了。停增量同步的时间点要选在业务低峰期，比如凌晨两点，然后快速切换写路由，整个过程控制在五分钟以内。
最后一步是回退预案。就算前面所有步骤都顺顺利利，你也不能保证新库在运行一段时间后不出幺蛾子。所以老库不要急着下线，至少保留一到两周的观察期，期间老库可以降级成只读模式，或者干脆保持双写但不再读。这样万一新库出现性能瓶颈或者数据问题，你还能快速回退。我见过不少团队，迁移完第二天就把老库服务器还给机房了，结果第三周新库出了个大Bug，只能从备份恢复数据，那叫一个惨。
回头再看整个迁移流程，你会发现真正难的其实不是技术，而是节奏控制。每一步都要有验证，每一步都要有回退方案，每一步都要盯紧数据一致性。Java生态里能用的工具很多，但工具只是辅助，关键还是你心里有没有一张清晰的路线图。平滑升级不踩坑，靠的不是运气，而是把每个细节都想到位，把每条退路都留好。下次你再遇到数据库迁移的项目，别急着敲代码，先花两天时间把流程设计清楚，这比什么都值。
