数据同步的需求在项目当中还是很常见的,我们其中做的一个业务平台就需要与多个第三方平台进行数据同步,实时性要求也比较高。所以这篇文章记录一下在不同场景下的数据同步方案。

1、同步策略

• 同步过程是全量同步还是增量同步
• 是否是异构数据库
• 同步方法
  • Select查询同步
  • Binlog同步
  • 业务事件同步
• 是否存储表映射或者逻辑处理的同步
• 同步的时效性
  • T+1
  • 小时级
  • 分钟级
  • 准实时
• 同步的过程是否对业务透明

1.1、全量同步与增量同步对比

全量同步，顾名思义，就是每天晚上夜间作业，将数据以数据库或者表为单位全量同步一次。适合数据量不大，每天既有新数据插入，又有修改和删除的场景。

增量同步相对全量同步来说，每个同步周期只对修改的内容进行同步。增量同步又有基于Select 批处理同步和CDC,业务事件同步三种方式

1.2 增量同步方式对比

• 基于Select 批处理同步
  • 通过select条件来实现,比如通过update_time来识别变化后的数据。
    • 缺点1：需要增加一个窗口时间,增加同步的安全性
    • 缺点2：不适合删除的场景,需要业务代码支持逻辑删除
  • 通过自增id来实现。记录上一次同步的id作为查询条件。
    • 缺点1:是通过id作为查询条件只适用于只新增不更新的场景
• 基于业务事件同步
  • 通过mybatis等orm框架机制,在拦截SQL那一层，解析sql将数据通过mq等方式发布出去
    • 缺点: 需要定时补偿一次,进行数据对账
• CDC同步
  • 一种用于捕捉和处理数据变化的技术，类似数据库原生主从复制，通过解析 binlog 来实现同步。

	Select	事件同步	CDC
实现原理	基于Select语句实现差异选择	基于Mybatis等orm框架拦截sql	通过捕获Binlog实现同步
实例	select * from table where update_time>$	-	-
适用场景	实时性不高，但需要可靠数据同步	实时性高,国产数据库	准实时同步
优点	灵活，不受数据库版本制约 可靠性好 实现简单	灵活，不受数据库版本制约 实现简单 灵活性比较好	实时性高 对应用无侵入
缺点	实时性不高 使用场景受限 对应用侵入	对组件有侵入 有可能会丢数据	需要解析BinLog 对数据库限制较大 实现复杂 对于项目有侵入且可能丢数据