一个数据迁移方案的设计

背景介绍

某个老业务一致运行在较久的系统上，而新业务运行在升级后的新系统上，此时有两个系统同时在运行。基于这种现状，同一个功能需要新旧系统上分别开发一遍。为了提高开发效率，需要将该老业务迁移到新系统上。新旧系统虽然对话领域的系统，在功能维度旧系统是新系统的子集。但是在实现上，两套系统完全不同。两套系统基于完全不同的表结构设计和系统设计。要想平滑的完成迁移，需要将旧系统依赖的数据完整的迁移到新系统中的库中。旧系统依赖2个库，7张表。新系统有相应的库和表与之对应，但是结构完全不同。以上就是本次数据迁移的业务背景。

面临的挑战

在以上的背景下，要设计一套方案。要求将数据不重不漏，高效的从A形态迁移为B形态。我们分析一下，方案面临一些几个挑战。

• 数据表完全异构

  • 旧库和新库表结构完全不同

• 业务方要求可以灵活的控制迁移范围

  • 业务方要求可以指定部分商家进行数据迁移

  • 也要求可以按照百分比进行批量迁移

• 数据量大

  • 数据迁移设计70w商家

  • 数据量最大的表有7kw条记录，数据量约70G

• 迁移时间窗口固定

  • 为了不影响商家正常使用，业务方要求迁移窗口为晚上且只有8个小时

方案设计

迁移一个商家数据

首先我们分析一下迁移一个商家，要做什么事情。一个商家的流程分析清楚了，迁移更多的商家不过是多循环几次的问题。这里体现了讲大问题（迁移70w商家）拆分为小问题（迁移一个商家）的思想。经过业务分析，迁移一个商家的数据可以分为7个模块，而且这7个模块直接存在依赖关系。例如，B模块的数据依赖A模块的数据迁移完成，并获取到外键，然后才能迁移B模块的数据。分析