在线数据迁移

是指将正在提供线上服务的数据，从一个地方迁移到另一个地方，整个迁移过程中要求不停机，服务不受影响。根据数据所处层次，可以分为cache迁移和存储迁移；根据数据迁移前后的变化，又可以分为平移和转移。

平移

是指迁移前后数据组织形式不变，比如Mysql从1个实例扩展为4个实例，Redis从4个端口扩展到16个端口，HBase从20台机器扩展到 30台机器等等。如果在最初的设计里就为以后的扩容缩容提供了方便，那么数据迁移工作就会简单很多，比如Mysql已经做了分库分表，扩展实例的时候，只需要多做几个从库，切换访问，xx将多余的库表删除即可。更进一步，在实现上已经做到全自动数据迁移，如 HBase，就更简单了：添加机器，手工修改配置或者系统自动发现，然后，沏一杯咖啡，等待系统完成迁移。

转移

是指数据迁移前后，数据组织形式发生了变化。多年前，某社交平台曾经为ID升级做过一次数据迁移，将ID由最初的自增算法修改为巧妙设计的UUID算法，这次迁移xx的挑战是要修改数据的主键，主键本来是数据的xx标识，它发生变化，也就意味着原来的数据不复存在，新的数据凭空产生，对于整个系统中所有业务流程、周边配套、上下游部门都会产生巨大的兼容性挑战。不过大部分数据迁移项目都不会修改主键，甚至不会修改数据本身，改变的只是数据的组织形式。比如某社交平台计数器原本为了节约存储空间，使用redis hash进行存储，后来为了提升批量查询的性能，迁移成 KV 形式；又比如某社交平台的转发列表和粉丝列表，最初都使用Mysql存储，后来为了更好的扩展性和成本，都迁移到HBase存储。

在线数据迁移xx的挑战是如何保证迁移过程服务不受影响。很多人将其比喻成“飞行过程中换发动机”“给行驶的汽车换轮胎”，但实际上并没有那么困难，一个入行一两年的技术人员，遵从一些经验指导，xx可以完成。下面就跟大家分享一下一些经验，作为抛砖引玉。

4个步骤

1、上线双写，同时写入新旧两种数据

2、历史数据离线搬迁，即离线将历史存量数据从旧系统搬到新系统

3、切读，即将读请求路由到新系统

4、清理沉淀，包括清理旧的数据，回收资源，及清理旧的代码逻辑，旧的配套系统等等，将迁移过程中的经验教训进行总结沉淀，将过程中开发或使用的工具进行通用化改造，以备下次使用

某些情况下，步骤一和步骤二也可能倒过来，先做历史数据搬迁，然后再写入新数据，这时候就需要谨慎的处理搬迁这段时间里产生的新数据，一般使用queue缓存写入的方式，称为“追数据”。

在线数据迁移并不是一项需要高深技术的工作，它更多需要的是对业务逻辑的把控，对操作流程的理解，对新旧系统特性的掌握，以及对细节的敬畏之心。（来源：InfoQ中文站）