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

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

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

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

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

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

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

我们会做下面的验证：

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

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

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

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

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

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

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

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

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

（编辑：核心网）

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