不停服数据迁移方案

系统随着业务的发展，系统技术选型和层级划分都会进行或大或小的调整，在系统调整过程中，沉淀下来的数据需要得到良好的梳理和传承，对于非流水的属性类数据，需要随着系统的重构重新迁移、组合，但是在线的系统不允许大规模的停服来配合迁移，这个时候需要一套热迁移或者准热迁移的方案，下面我们来讨论下。

查了下类似的经验和方案，主要分一下几类：

1、完全停服，全量部署至新服务、迁移至新数据源（单写）   推荐指数 ☆☆☆

优点：逻辑简单、操作成本较低

缺点：停服影响用户体验，且不具备回滚方案，如上线后遇到问题风险较大

2、部分功能降级，停止写操作，迁移至新数据源（单写）  推荐指数 ☆☆

优点：对用户影响减小

缺点：需具备配合服务降级相关的流量控制能力，不具备回滚方案

3、停服部署、在原服务的基础上增加双写功能、数据源也采用双写    推荐指数 ☆☆☆☆

优点：可通过开关控制双写、具备回滚方案

缺点：操作成本较高、对接过程中的迭代需要同步支持、需要停服

4、不停服，增加缓冲层（MQ），数据迁移过程中增量数据写入缓存，在数据迁移完成、缓冲层数据消费完成后，打开开关开始双写数据库   推荐指数 ☆☆☆☆☆

优点：对用户无感，有回滚方案

缺点：操作成本高、方案操作节点、引入组件较多、研发和测试流程需要严格把控

针对五星方案操作流程图：

 

几个需要关注的点：

1、业务系统数据是否有中间态，双写上线时的在途数据兼容

2、数据迁移前业务系统数据是否需要前置对账，切割存量、轻装前行

3、双写工具是否能通用？