首页手记高并发场景下转移表的处理过程探讨

高并发场景下转移表的处理过程探讨

标签：

Java

前提

技术调整，现在需要将表A从数据库B转移到数据库C里，成为新表D。

这篇文章主要是分享一下我们的方案

详细方案

调研（通过监控等，多个系统有使用）整理出所有涉及表A的SQL
新库上创建新表
在原有相关方法上添加开关，允许：
1）更新操作-同时更新（包括写）表A和表D
2）更新操作-只更新（包括写）表A
3）更新操作-只更新（包括写）表D
4）查询操作-单独查表A
5）查询操作-单独查表D
6）查询操作-同时查表A和表D记录不一致情况
这里需要注意，同一个方法可能要使用多个开关，多个开关不能有更新顺序问题。
刚开始上线时，开关控制只操作表A，不去操作表D
都发布上线完毕后（比如我们集群有几百台机器，不能让部分单写部分双写，否则表D数据是否哪个点开始应该算起就模糊了），开关调整为双写
之后根据需要导入原有的数据（某些场景特殊一点，只会差最近一天或几天，保证双写持续指定天数，新表可能已经覆盖所有数据，就不需要导数据了）
当表D按照设计和计划已经应该有需要使用的数据时，打开双写检查，对比，有问题的地方调整，直到没有不一致。
之后就剩删除之前操作表A的代码了。
这里我们在讨论时打成了一个共识，所有在涉及到调整的地方都要用到开关，所有开关都记录到一个新文件里，这样在删除老代码时直接通过新文件去查找，这种代价是最小的，也不容易出错。很多技术升级都会忽略掉删除老代码或过渡期代码，导致许多走不到的逻辑一直堆在那里，之后每次修改到这里都要浪费不少时间，后来的人需要不断的思考当时这里这样写是为什么，很少会晓得许多代码本来是不该存在的。
表A没使用时不能直接drop掉，而是先进行rename，这样一旦之前改的不全，可以迅速rename回来，确认没影响，再找个时间单独处理掉。这也是一个提醒，许多操作都要想好如何回滚，尽量给自己一个可以吃后悔药的机会。