初始化接口VS增量同步实现全量同步VS全量同步VS导数完成数据初始化需求

1 需求

作为数据中台，下游对接的系统一张新表，需要用到全量的数据，大概有15w左右，现在的状态是我已经写好了增量同步的需求，但是初始化需求因为刚开始没有沟通清楚导致现在临时加东西

2 三种初始化方式

2.1 导数

一般的大公司允许从oa提数据库导出单，然后发送给下游指定的人接收，不过导出数据量一般有限制或者说可能受到安全部门审查。另外下游一般会专门写一个方法实现导入。

对上游有好处，但是对接方麻烦，具体用不用就看你们协商了

2.2 上游写一个初始化接口供下游调

双方都需要写代码配合，并且接口需要考虑到对生产库的影响，一次请求的数据量不能太多。

两边都要写代码，比较公平，但是双份代码。

2.3 MQ增量实现全量同步

在生产库中将sync字段全部改为0（未同步），然后按照增量的方式扫描sync=0（是否发送给下游的依据是sync=0）的字段同步给下游，每次都会扫描500条记录，发送完后就会修改sync=2（表示同步成功）。

好处是快捷方便。
坏处就是需要全量改生产库，有两个问题需要确定，首先是有哪些下游接入过这张表，更改sync字段值会不会造成广播风暴；其次是数据库运维的审查能不能过

2.4 在增量的接口上加一个全量同步的功能

如果2.3中不允许改库，那么可以通过在增量的接口上加一个全量同步的功能，发送mq消息的行为可以复用，需要借助定时任务传递参数确定是走全量还是增量同步，另外在全量的时候可以将主键id作为游标和位点，在同步失败时打印位点，下次重启任务时可以用这个位点接着同步。具体可以参考xxl-job的分片广播+单播及其应用实战的第三节举例。

好处是2.3不能改库时使用这个方法对旧有方法改动也不大；坏处是改动比2.3大很多