1、CDC延迟概述：什么是CDC延迟、延迟对业务的影响、延迟的典型表现

大家好，我是老赵。做数据架构十几年，CDC（Change Data Capture）这块我踩过的坑，估计能写一本小册子。今天咱们先聊聊最基础、也最让人头疼的问题——延迟。

说白了，CDC延迟就是数据从源头数据库发生变化，到最终被消费端拿到，中间隔了多长时间。这个时间差，就是延迟。你想想看，一个订单在MySQL里已经支付成功了，但下游的实时风控系统过了5分钟才收到这条变更，这5分钟就是延迟。

1.1 延迟对业务的影响——真金白银的教训

延迟不是技术指标，它是业务损失。我经历过一个真实案例：某电商大促期间，库存系统用了CDC同步，结果延迟飙到30秒。用户下单时显示有货，支付后却被告知缺货。那天的客诉量直接翻了三倍。

具体来说，延迟会带来这几类伤害：

• 数据不一致：报表系统看到的数据和业务库对不上，管理层拍板时用的都是过期数据。
• 实时决策失效：风控、推荐、监控这些场景，延迟超过阈值就等于废了。比如反欺诈系统，5秒的延迟可能让一笔欺诈交易溜过去。
• 下游链路雪崩：一个CDC延迟，可能导致下游十几个系统都拿到脏数据，排查起来想死的心都有。

1.2 延迟的典型表现——三种常见“症状”

延迟不是单一现象，它通常表现为三种形态。我习惯把它们叫做“三兄弟”：

表现类型	现象描述	常见原因
数据滞后	消费端看到的数据比源头慢了几秒甚至几分钟	源库压力大、网络抖动、消费端处理慢
重复消费	同一条变更被消费端处理了多次	offset提交失败、重启后重放、幂等性缺失
数据丢失	某些变更记录永远没到达消费端	日志清理、网络丢包、消费端崩溃

数据滞后是最常见的。我记得有一次排查，发现Kafka的消费者lag一直在涨，但CPU和内存都不高。最后定位到是消费端的数据库连接池配小了，处理一条数据要等200ms。说白了，不是CDC工具慢，是下游自己消化不了。

重复消费这个坑，我估计做过实时数据的人都遇到过。Kafka的at-least-once语义，加上消费者重启时offset没提交，就会重复。嗯，这里要注意：重复消费不一定是CDC的问题，但延迟会导致重复的概率变大——因为延迟越高，消费者越容易在重启时读到旧offset。

数据丢失是最严重的。我见过一个案例：MySQL的binlog保留时间设了24小时，结果CDC任务因为网络故障停了2天，恢复后binlog已经被清理了。那几天的数据，彻底丢了。所以，binlog保留时间一定要大于CDC任务的最大容忍停机时间，这是铁律。

1.3 一张图看懂CDC延迟全景

下面这张图，是我自己总结的CDC延迟全景图。它把延迟从源头到消费端的路径画清楚了，后面几章我们会逐个环节拆解。

从这张图你能看到，延迟不是某一个环节的问题。它可能发生在源头、捕获层、消息队列、消费端，甚至多个环节叠加。我个人习惯把延迟排查比作“管道疏通”——你得一段一段摸，才能找到堵点。