数据同步如何保证不重、不丢、不错？一文讲清全量、增量、校验和异常处理

企业做数据同步，真正危险的往往不是任务报错，而是任务显示“成功”,数据却已经重复、遗漏或失真。·历史订单发生修改，增量任务却没有捕获；·金额字段进入目标库后精度被截断；·任务失败后从头重跑，又制造出重复数据。因此，可靠的数据同步不能只回答“能不能把数据搬过去”,还要回答三个问题：·源端发生的变化有没有全部到达?·到达后的内容和业务含义是否仍然正确?ERP离线处理引擎(业务包)一、先理解“不重、不丢、不错”“不重”,不是同步结束后再做一次去重，而是同一批数据被重复读取、重复投递或任务重复启动时，目标端最终仍然只有一份。“不丢”,也不只是源表和目标表总行数相同。新增、修改、删除，以及迟到数据、边界数据、停机期间的数据，都可能被遗漏。“不错”,则要求字段值、数据类型、编码格式、关联关系和业务口径保持一致。两边各有100万行，不代表金额没有被截断、状态没有映射错误、时间没有因时区变化而偏移。所以，一条可信的同步链路至少要保证四层一致：记录完整、主键唯一、字段正确、业务可解释。新增/修改/删除都能捕获四层一致可信同步记录完整字段正确字段、结构、口径保持正确业务可解释二、全量同步：难点不是“搬完”,而是建立一致起点全量同步常用于首次上线、目标表重建、历史数据回补和故障恢复。最简单的做法，是清空目标表，再把源表全部写入。但只要源系统仍在产生业务，全量期间就可能出现“动态快照”问题。例如，全量任务10点开始、12点结束。期间新增或修改的数据，可能被重复读取，也可能被跳过。最后得到的既不是10点快照，也不是12点状更可靠的方案是“一致性快照+增量追平”:·在同一快照口径下读取历史数据；·全量写入结束后，从已记录位点消费增量；·增量追平后，再切换为持续同步。关键在于：全量与增量必须共享一个明确的交接点。没有交接点，两段任务之间会出现空档；范围重叠却没有幂等机制，又会产生重复。大表全量还要合理分片。按主键区间、日期分区或哈希分桶读取，通常比不断增加offset更稳定，也便于失败后只重跑局部区间。在FineDataLink中，可以根据场景选择追加写入、清空目标表后写入，或基于标识字段执行新增、修改和删除。初始化阶段先装载历史数据，再以标识字段衔接后续变化，更容易把“第一次搬全”和“后续持续更新”连成一条完整链路。增量同步只处理上次任务之后发生变化的数据，效率更高，但同步边界也最容易出错。按照“主键大于上次最大值”读取，适合只新增、不修改的流水表。它无法识别历史记录修改和删除；旧数据补录、主键回填或主键不连续，也可能造成误判。2.更新时间戳按照update_time读取新增和修改，是定时同步中最常见的方式。但只使用“update_time>上次最大时间”并不安全。多条数据可能拥有相同时间戳，数据库时间精度也可能不足，位于边界上的记录容易被漏掉。更稳妥的方法是使用“时间戳+主键”组成复合水位；也可以把起点向前重叠数秒，再依靠目标端幂等消除重复。例如，上次同步到10:00:00,本次可以从09:59:55开始重新读取。多取几秒的数据并不可怕，只要目标端能够识别同一条记录；真正危险的是把边界卡得过死，导致数据永久遗漏。增量同步的原则不是“绝不重复读取”,而是“允许少量重叠，但不能国任务1054N嚣数据转换数据输入∨田DB表输入API输入盛简道云输入MongoD输入SAPRFC输入DB表输入新增计算列保存国数据输出∨日DB表输出参数输出API输出些简道云输出注册时间#购买数量T合同签约时间2017-09-1900..65222T是否已经交货下单时间、发货日期和开票日期描述业务何时发生，却不一定反映数据何时修改。三个月前的订单今天被修正，如果只按下单时间取增量，这次变化不会进入目标端。表，适合高频变化和低延迟场景。但CDC也不是开箱即“绝对不丢”。日志保留时间不足、读取位点失效、表没有稳定主键、DDL变更不兼容，都可能破坏同步连续性。FineDataLink可基于CDC、Binlog、LogMiner等方式进行实时增量同步。部署时仍要检查日志是否开启、保留多久、断点是否有效，以及目标表用什么字段识别同一条记录。数据连接MySOL存在更新或励除事件时，需选择字段作为主键，以确保数据的唯一性同步类型◎存量+增量同步仅增量同步存量+增量同步：先对所有存量数据完成同步，随四、如何保证“不重”:核心不是去重，而是幂等网络超时、消费端重启、写入确认丢失，都可能让同一批数据再次到达目标端。工程上更常见的方案是：允许数据至少投递一次，但要求目标端重复执行后结果不变。这就是幂等。网络超时消费重启确认丢失同一批数据可能重复到达唯一键订单ID/客户ID/来源+单号位点/版本号/更新时间提交顺序先写目标端，再提交断点错误顺序先提交断点→写入失败→漏数正确顺序先写入成功→再提交断点实现幂等，需要四个条件。第一，建立稳定的唯一键。订单ID、客户ID,或者“来源系统+业务单号”,必须能够唯一识别业务对象。第二，使用upsert或merge,而不是无条件append:·已经存在，则更新；·内容没有变化，则不重复处理。第三，为事件建立版本。可以使用日志位点、版本号或更新时间判断新旧，避免较晚到达的旧事件覆盖最新状态。第四，正确安排提交顺序。应先完成目标端写入，再提交同步断点。假设一批数据已经从源端读取，但还没有写入目标端，系统就提前更新了断点。此时一旦写入失败，任务重新启动后会直接从新断点继续，中间的数据将被永久跳过。反过来，如果目标端已经写入成功，但断点暂时没有提交，任务重启后最多只是重复读取。只要目标端具备幂等能力，重复数据就能被识别和覆盖。因此，可靠同步宁可接受“可控重复”,也不能接受“不可恢复的遗漏”。文件去向demo后台sftp测试连接五、如何保证“不丢”:覆盖数据的完整生命周期很多同步任务只处理新增和修改，却没有处理删除。源系统删除一张无效订单，目标表仍然保留，报表就会继续统计，业务结果已经失真。删除同步一般有三种方式：·使用is_deleted等字段同步逻辑删除；·周期性执行快照比对，识别源端已不存在的记录。除此之外，还要处理三类隐性丢数。业务早已发生，但因接口积压、人工补录或上游故障，过一段时间才进入源表。可以设置回看窗口，定期重刷最近若干天的数据。删除同步方式删除同步方式物理删除CDC捕获删除事件删除可同步，异常可补回识别源端已不存在记录!隐性丢数场景与应对迟到数据设置回看窗口，定期重刷断点失效重做受影响范围，再建增量起点乱序数据不丢读取量成功量先发生的事件后到，后发生的事件先到。目标端不能只看接收顺序，而应结合版本号或业务更新时间判断最新状态，避免旧事件覆盖新结果。任务停机时间超过日志保留周期，原来的位点已经无法继续读取。此时不能直接从最新位置启动，而要重做受影响范围的全量或补数，再建立新的增量起点。此外，还要记录源端读取位点、目标端写入位点、每批读取量、成功量、失败量和最大更新时间。如果系统只显示“任务成功”,却无法回答“同步到了哪一条、哪个时间点”,一旦发生问题，就只能依赖人工猜测和整表重跑。真正的不丢，不是从未失败，而是失败后知道停在哪里、缺了哪一段、设面的明去及射设面的明去及射里源器目标表之六、如何保证“不错”:校验要从技术层走到业务层行数校验只能发现“大面积少了或多了”,无法证明内容正确。一套可靠的校验机制，至少要分五层。比较源端读取量、过滤量、成功写入量和失败量。原则上应满足：读取量=成功写入量+过滤量+失败量。任何一项没有明确去向，都意味着链路存在黑箱。检查主键和业务单号是否重复，一对一关系是否变成一对多。重复通常说明幂等规则失效，或不同系统的标识发生冲突。3.汇总校验按日期、组织、地区、订单状态等维度，比对记录数、金额和数量。总量一致而分组不一致，通常意味着字段映射或状态转换出错。例如，总销售额完全相同，但华东地区金额减少、华南地区金额增加，可能是地区编码映射发生了错位。4.内容校验对关键字段按固定顺序拼接并计算哈希。同一主键哈希不同，就说明内容不一致；大表可以先按分区校验，再缩小范围。需要注意的是，计算哈希前必须统一空值、日期格式、小数精度和字符编码，否则同一条数据也可能计算出不同结果。五层校验技术同步成功≠数据可用·退款金额不能高于实付金额；·发货时间不能早于下单时间；·客户编码必须存在于主数据中；·已关闭订单不能继续产生发货记录。技术同步成功，只能说明数据被写进去了；业务规则校验通过，才能说FineDataLink的任务日志能够暴露源端增量读取、目标端写入、连接状态和日志断点等问题。把这些运行信息与行数差异、金额差异、延迟时长一起纳入监控，校验就能从月底人工对账，转变为同步过程中的持续控制。同步失败后无限重试，可能把临时问题变成系统雪崩，也可能让错误数据被反复放大。FineDataLink数据平台明细(前1000条数据)菠萝6001图图菠萝甘蔗356.0525.0查看异常明性例如网络超时、数据库短暂不可用、接口限流。这类问题可以采用指数退避重试，并设置最大次数，避免任务集中冲击上例如字段超长、日期格式错误、必填字段为空。这类问题反复重试通常没有意义，应进入脏数据表或隔离区，保留原始记录、失败原因和批次号，让正常数据继续执行。异常分类恢复异常分类恢复字段超长/日期错误/必填为空隔离到脏数据表网络超时/库短暂不可用/接口限流指数退避重试字段删除/类型变化/主键调整目标结果例如源字段被删除、类型变化、主键规则调整、目标表结构不兼容。这类问题应立即停止相关链路并告警，避免错误继续向下游扩散。不是所有异常都适合重试。临时故障可以重试，数据错误需要隔离，结构变化必须人工确认。补数也必须遵循原来的唯一键、版本判断和校验规则，否则可能制造重复，或用旧数据覆盖新状态。例如，补录三天前遗漏的订单时，不能无条件覆盖目标表中的同一订单。因为这张订单可能已经在今天被修改，三天前的旧版本反而会把新状态覆盖掉。因此，一套可恢复机制必须同时保留：异常处理真正要解决的，不只是“怎样把任务重新跑起来”,而是怎样在恢复任务的同时，不制造新的重复、遗漏和错误。临时故障临时故障指数退避+最大次数数据错误脏数据表/正常数据继续同步失败停止并人工确认任务批次版本判断不是简