),源数据源不停写,然后历史数据迁移结束后,停写源数据源,通过脚本或者增量日志进行数据最平,当然停机时间相对较短(停机时间取决于历史数据迁移时间内业务增量),对于核心业务数据迁移,在低峰期操作停写追平数据也是可以接受的...对于非核心业务或者数据增量比较小的业务场景中,在低峰期采用停机迁移方案是比较可取的,但是在数据量比较大并且业务增量也比较大的场景中,衡量和评估影响和操作复杂度两个维度,非严格停机迁移一般是比较可取的。...b.开启增量同步
在服务层收敛目标表的所有写操作,开启增量同步,也就是开启双写,可以在历史数据开始迁移时开启双写,需要数据的是,新数据源更新操作可能会出现数据不存在,可直接跳过。...c.追平数据
记录历史数据迁移的开始和结束位点,然后捞取此期间的所有写操作日志,分析发生过更新操作的业务id,然后通过业务脚本进行追平,但是在极端情况下也可能出现数据追平的过程中由于源数据源未停写...b.增量数据同步
该方案与2类似,但是实现方式相对更优雅一点,首先基于消息的天然异步属性,将原来的同步操作变成异步(延迟可接受),然后kafka有一定的数据存储能力,对于consumer崩溃后恢复或者重启后