系统迁移涉及到的方案

背景：目前在做公司系统迁移的任务，需要将一个系统的能力拆分到一个新的系统，涉及到DB的的一些数据

步骤：

（1）首先涉及架构方案，比如针对数据的处理，存量数据和增量的数据。

存量数据同步的方式：

存量的数据可以通过离线表清洗出id，然后通过接口调用的方式进行数据迁移。

增量数据同步的方式：

 1、使用消息的方式：增量数据就需要数据进行双写，比如商家修改一条数据，则先在原有系统A操作，然后发送一个消息给A，然后A在消费这个消息通过接口调用B系统，将数据异步的写入到B，这样做的好处是，可以使用消息重试的特性防止接口调用失败

2、使用DB的drc同步方式，B系统的DB监听A系统的db变更消息，进行数据的同步

最终我这边选择的方式，使用的是方案1

 使用方案1可能会遇到的几个问题

  1、如果A系统频繁的修改，消息有延迟该如何处理？

       使用分布式锁对当前的修改记录锁住，如果第二次修改到来，第一次没有完成，则获取锁失败。这样分布式锁就可以保证这次修改的数据是原子的操作。

2、如何同步过去的数据是最新的？

       通过分布式的锁保证了当前执行的数据是正确的，每次消息到来，都去db查询最新的数据进行更新。

3、增量，存量数据执行的过程，保证数据的一致性？

先存量先上线，DB有数据则更新，否则插入。然后在存量同步，有则更新，没有则插入。这样就保证数据的一致性。   

（2）数据的核对

要保证A，B系统数据的一致性，使用实时核对的方式，调用A，B系统接口进行数据比对，如果发现数据不一致，则使用同步订正工具进行数据订正

（3）数据库如果不可用，怎么处理？

目前mysql的DB都是主备的方式，主写，从读。读写分离。可以使用failover +消息的方式进行DB切换的方式。

如果主库挂掉，那么写往faileover里面写，读的时候从 从库+failover库读取。如果主库恢复了，则将failover数据库中数据删除，然后使用消息出发将数据写入到主库，然后在同步到从库，保证永远都是主库写入到从库。