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

我们用Scalding来管理我们的MapReduce任务.Scalding是一个用Scala写成的非常有用的库,用它来写MapReduce任务非常容(写一个简单任务的话连十行代码都不用).在这个案例中,我们用Scalding来找出所有的订阅数据.具体步骤如下：

• 写个Scalding任务来生成所有需要迁移的订阅数据的ID列表；
• 做一次大型的、多线程的迁移操作,来并行地把所有需要迁移的订阅数据快速拷贝过去；
• 当迁移结束之后,再运行一次Scalding任务,确保所有旧订阅表中的订阅数据都迁移到了新表里,没有遗漏；

第二部分：切换所有的读操作

现在新旧两张数据表中的数据都处于同步状态了,下一步就是把所有的读操作都迁移到新数据表上来.

到这一步时,所有的读操作都仍然在使用旧的用户表：我们要切换到新的订阅表上来.

我们要很确信可以从新的订阅表中正常读出数据,这也意味着我们的订阅数据必须是一致的.我们用GitHub的Scientist来帮我们做验证.Scientist是一个Ruby库,可以让我们执行测试,比较两段不同的代码的执行结果,如果在生产环境中两种表述会产生不同的结果,它就会发出警告.有了Scientist,我们就可以实时地为不同的结果产生告警和获得指标.万一测试用的代码产生了错误也没有关系,我们的程序的其它部分并不会受到影响.

我们会做下面的验证：

• 用Scientist去分别从订阅表和用户表中读出数据；
• 如果结果不同,就抛出错误,提醒技术人员数据不一致；

GitHub的Scientist让我们可以同时从两张表中读出数据,并且比较结果.如果验证通过,所有数据都能对得上,我们就可以从新表中读入数据了.

我们的验证很成功：所有的读操作都使用新的订阅表了.

第三部分：切换所有写操作

接下来,我们要把所有写操作切换到新的数据表上来.我们的目标是渐进式地推进这些变动,因此我们要采用非常细致的战术.

到目前为止,我们一直在向旧数据表中写入数据,并复制到新表中：

现在我们想调换这个顺序：向新数据表中写入数据,并且同步到旧数据表中去.通过保持这两张数据表之间的数据一致,我们就可以不断地做增量更新,并且细致地观察每次改动的影响.

把所有处理订阅数据的代码都重构掉,这一块应该是整个迁移过程中最有挑战性的了.Stripe处理订阅操作的逻辑分布在若干个服务的几千行代码中.

成功重构的关键就在于我们的渐进式流程：我们会尽可能地把数据处理逻辑限制到最小的范围内,这样我们就可以很小心地应用每一次改动.在每个阶段里,我们的新旧两张表中的数据都会保持一致.

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

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

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

第四部分：删除旧数据

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

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

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

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

最后的结论

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

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

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

作者：Jacqueline Xu

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

（编辑：ASP站长网）