同步方式
全量同步：周期的将源系统特定表的所有数据复制到目标系统中。
- 简单可靠
- 数据量较小，数据实时性要求不高的场景下首选
- 不满足增量同步条件的场景下选择
- 不适合大量数据同步的场景
增量同步：仅同步上一个同步周期之后，源系统表变动的数据。
- 时间戳+业务主键：源系统增加时间戳，周期抽取时根据时间戳圈定抽取范围，落库时根据业务主键更新对应数据
- 必须存在更新时间戳及业务主键
- 暂不支持数据物理删除
- 数据量较大，数据实时性要求较高场景下推荐
- 建议兼容全量
表结构设计
获取源系统表结构，目的系统数据库中建立以下类型表
临时表：临时表暂存批量提交的数据。定时任务触发，从SFTP、共享目录下，获取推送的文件；批量解析并提交到临时表中；数据完全插入临时表
影子表：影子表对照业务系统建表，用于保存业务系统源数据（全局临时表效果更佳）。临时表入库阶段完成后，将临时表中数据单次提交至影子表中。临时表-影子表，分段提交的设计，实现大批量数据的事务管理
结果表：结果表面向业务逻辑，提供虚拟数据层服务。结果表屏蔽了源系统表设计的细节，保存源数据预处理后的结果
在数据预处理过程中，抽取业务流程所需字段需撰写SQL实现，则保证源系统与目的系统表结构设计一致尤为重要。
文件入库流程
文件获取：从SFTP或NFS中获取源数据文件，瓶颈在网速，调整数据量是解决问题的关键
数据加载：将文件载入内存，为后续解析入库做准备，瓶颈在IO，选择合适的IO模型是解决问题的关键
数据解析与预处理：例如header与body遵循不同的解析逻辑，瓶颈在CPU，满足任务划分、数据划分的前提下，多线程是解决问题的关键
数据入库：将处理好的数据落库，瓶颈在DB，批量提交与事务管理是解决问题的关键。
Tips:
定时任务触发文件入库流程，xxljob集群调度存在多次发起的风险，目的系统解析入库亦建议单台服务器执行，需要实现分布式锁，建议采用数据库CAS锁的方式实现
源系统按批次进行抽数、推送，相同批次中可能既有增量也有全量，设计初期需考虑增量全量兼容的问题
交互数据为文本，且数据文件中有中文，采用字符流实现，批次读入，禁止未判定数据文件大小的全量Load操作
下载、载入瓶颈在IO，单线程即可，解析数据及数据入库考虑多线程实现，为文件服务单独配置线程池，批量读取后多线程解析并入库
合并SQL，减少SQL语句解析次数，减少IO，减少数据库日志量，降低日志刷盘的数据量和频率，但需要注意合并后SQL的长度，以及事务大小，即预估批量数据大小，设置合适的阈值
数据首先批量提交至临时表中，待所有数据落库完成，再刷入影子表中，分段提交能够在海量数据的场景下实现事务管理
线程池采用ArrayBlockingQueue、ThreadPoolExcecutor.callerRunsPolicy即可，不允许丢失数据
读取文件时，需判定大小，尽量批次读入
记得关闭流
事务管理，包括临时表落库批量提交
文件生成时按行生成，读取时按行读取，达到批量提交阈值，则触发自动提交
文件处理可拆分为读取、解析、入库三个阶段，海量数据还可以考虑数据划分、任务划分，并行实现
