如何在不停机的情况下，完成百万级数据跨表迁移？

对于每一处代码逻辑,我们都会用全面的方法来保证我们的改动是安全的.我们不能简单地用新数据替换旧数据：每一块逻辑都必须经过审重地考虑.不管我们漏掉了哪种特殊情况,都有可能会导致最终的数据不一致.幸运的是,我们可以在整个过程中不断地运行Scientist测试来提醒我们哪里可能会有不一致的情况发生.

我们简化了的新写入方式大概是这样的：

到最后我们加入逻辑,如果有任何调用这样过期的订阅数据的情况发生,我们都会强制抛出一个错误.这样我们就可以保证再也没有代码会用到它了.

第四部分：删除旧数据

我们最后也是最有成就感的一步,就是把写入旧数据表的代码删掉,最后再把旧数据表删掉.

当我们确认再没有代码依赖已被淘汰的旧订阅数据模型时,我们就再也不用写入旧数据表中了：

做了这些改动之后,我们的代码就再也不用使用旧数据表了,新的数据表就成了唯一的数据来源.

然后我们就可以删除掉我们的用户对象中的所有订阅数据了,并且我们会慢慢地渐进式地做删除操作.首先每当我们加载订阅数据时,我们都会自动地清空数据,最后会再运行一次Scalding任务以及迁移操作,来找出所有遗漏的未被删除的数据.最终我们会得到期望的数据模型：

最后的结论

在迁移的同时还要保证Stripe的API是一致的,这事很复杂.我们有下面这些经验可以和大家分享：

• 我们总结出了四阶段迁移策略,这让我们可以在生产环境中没有任何停机时间就可以完成数据切换操作.
• 我们采用Hadoop用离线的方式进行了数据处理,这让我们可以用MapReduce并行地处理大量数据,而不是依靠对生产库进行代价昂贵的检索操作.
• 我们所有的改动都是渐进式的.每一次我们改动的代码量都绝对不会超过几百行.
• 我们所有的改动都是高度透明和可观测的.哪怕生产环境中有一条数据不一致,Scientist测试都会立刻向我们告警.通过这种办法,我们可以确信我们的迁移操作是安全的.

我们在Stripe已经做过许多次在线迁移了,经过实践检验这些经验非常有效.希望别的团队在做大规模数据迁移时,我们的这些经验也可以对他们有所帮助.

作者：Jacqueline Xu

文章来自微信公众号：聊聊架构

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!