如何实现不停机更换数据库？
在设计迁移方案的时候，一定要做到，每一步都是可逆的。要保证，每执行一个步骤后，一旦出现问题，能快速地回滚到上一个步骤。
订单库迁移方案：
- 把旧库复制到新库，同时新旧2个库需要实时同步。同步程序有问题，把同步程序停掉。
- 订单服务改造，主要修改DAO层：支持双写、支持双读，并设置有开关，控制读写旧库还是新库。
- 新订单服务上线后，先读写旧库，运行一段时间稳定后，再开启写新库（先写旧，再写新，以写旧为主）。有问题，回滚到旧版服务。
- 比对任务比对新旧库数据，不一致需要补偿。直至没有旧库写成功，新库写失败的情况出现。对比程序也没有发现新旧两个库的数据有不一致的情况，这个时候，我们就可以认为，新旧两个库的数据是一直保持同步的。
- 切流量，读切换到新库。出问题直接回滚到读旧库。
- 稳定一段时间，停掉比对服务，写状态改为只写新库。下线旧库，切换完成。
比对和补偿程序
像订单这类时效性强的数据，是比较好对比和补偿的。因为订单一旦完成之后，就几乎不会再变了，那我们的对比和补偿程序，就可以依据订单完成时间，每次只对比这个时间窗口内完成的订单。补偿的逻辑也很简单，发现不一致的情况后，直接用旧库的订单数据覆盖新库的订单数据就可以了。
像商品这种随时都可能会变化的数据，需要利用更新时间。每次在旧库取一个更新时间窗口内的数据，去新库上找相同主键的数据进行对比，发现数据不一致，还要对比一下更新时间。新库更新时间更晚，暂时不要覆盖可能是新修改了数据。还有就是，窗口结束时间需要选比当前时间早一分钟，避免比对正在写入的数据。
此文章为3月Day20学习笔记，内容来源于极客时间《后端存储实战课》
