延迟监控指标体系：端到端延迟、解析延迟、传输延迟、写入延迟
做 CDC 同步，最怕什么？
不是数据丢了，也不是同步挂了——而是延迟在慢慢变大，你却不知道。等业务方找上门来投诉数据对不上，那时候再排查，往往已经晚了。
我这些年处理过的延迟故障，少说也有几十起。说实话，大部分问题如果早一点发现，根本不会演变成事故。所以这一章，我想跟你聊聊延迟监控的四个核心指标。搞懂了它们，你就能在延迟刚冒头的时候把它掐掉。
核心观点：延迟不是单一指标，而是一条链。端到端延迟 = 解析延迟 + 传输延迟 + 写入延迟。每一段都要监控，每一段都要设阈值。
为什么要把延迟拆成三段？
你可能觉得，直接看「从源库产生到目标库写入」的总耗时不就行了？
嗯，我以前也这么想。直到有一次，端到端延迟显示 5 秒，业务方说能接受。但实际排查发现，解析阶段就占了 4.5 秒，写入只有 0.5 秒。这意味着什么？意味着源库的 binlog 已经堆积成山了，解析器快扛不住了。如果只看总延迟，你根本不知道瓶颈在哪。
所以，我建议你把延迟拆成三段来监控：
- 解析延迟：从源库产生变更到 CDC 组件完成日志解析
- 传输延迟：从解析完成到数据到达目标端网络层
- 写入延迟：从数据到达目标端到实际写入目标库
这三段加起来，就是端到端延迟。每一段都有不同的根因，也需要不同的优化手段。
端到端延迟：业务视角的「温度计」
端到端延迟是业务方最关心的指标。说白了，就是「源库改了数据，目标库多久能看到」。
我个人习惯把这个指标分成三个等级：
| 等级 | 延迟范围 | 业务影响 | 建议动作 |
|---|---|---|---|
| 健康 | < 1 秒 | 实时性高，业务无感知 | 保持现状，定期巡检 |
| 警告 | 1 ~ 10 秒 | 部分场景可接受，但需关注 | 检查各分段延迟，定位瓶颈 |
| 危险 | > 10 秒 | 业务明显感知，可能产生数据不一致 | 立即告警，启动应急流程 |
不过要注意，端到端延迟只是一个「结果指标」。它告诉你出问题了，但不告诉你问题在哪。所以，我们还得看分段指标。
解析延迟：最容易出问题的环节
解析延迟，指的是 CDC 组件从源库拉取 binlog（或类似日志）并解析成内部格式所花的时间。
这个环节我踩过的坑最多。有一次，某个 MySQL 实例的 binlog 文件突然变大，单文件超过 10GB。解析器读文件的速度跟不上写入速度，解析延迟从 200ms 飙升到 30 秒。我当时盯着监控面板，端到端延迟才 31 秒，完全没意识到解析段已经快崩了。
从那以后，我强制团队必须单独监控解析延迟。常见的根因有：
- 源库日志堆积：大事务、DDL 操作、批量更新
- 解析器性能不足：CPU 瓶颈、内存不足、线程数配置不合理
- 网络抖动：源库到 CDC 节点的网络不稳定
我的经验：解析延迟的阈值建议设为端到端延迟阈值的 50%。如果解析延迟占比超过 60%，优先排查源库和解析器配置。
传输延迟：网络层面的「隐形杀手」
传输延迟，是数据从解析完成到到达目标端网络层的时间。说白了，就是数据在「路上」花了多久。
这个指标往往被忽略。为什么？因为很多监控工具只统计「发送时间」和「接收时间」，不统计中间的排队和重试。但实际上，传输延迟最能反映网络链路的健康度。
我记得有一次，跨地域同步的传输延迟突然从 50ms 涨到 2 秒。排查了半天，发现是中间某个交换机的 MTU 配置不对，导致大包频繁分片重传。如果只看端到端延迟，你只会觉得「同步变慢了」，根本想不到是网络层的问题。
传输延迟的常见影响因素：
- 带宽瓶颈：数据量超过链路带宽
- 网络抖动：丢包、重传、延迟抖动
- 队列堆积：发送端或接收端的缓冲区满了
- 序列化/反序列化开销：数据格式转换耗时
注意：传输延迟不是简单的「ping 延迟」。它包含了数据在发送缓冲区排队的时间、网络传输时间、接收端处理时间。建议用 CDC 组件内部埋点来统计，而不是依赖网络层的 ICMP 探测。
写入延迟：目标端的「最后一公里」
写入延迟，是数据到达目标端后，到实际写入目标库的时间。
这个指标直接反映了目标库的写入能力。我见过太多案例，解析和传输都正常，但写入延迟居高不下。为什么？因为目标库扛不住了。
有一次，某个同步链路的目标端是 Elasticsearch。业务方搞了个大促活动，写入量暴增 10 倍。ES 集群的写入线程池全部打满，写入延迟从 100ms 飙升到 15 秒。但解析延迟和传输延迟都正常，端到端延迟显示 15.2 秒。如果不拆开看，你根本不知道问题出在写入端。
写入延迟的常见根因：
- 目标库写入瓶颈：磁盘 IO 打满、索引锁冲突、连接池耗尽
- 数据转换开销：字段映射、类型转换、数据清洗
- 写入批次大小：批次太小导致频繁提交，批次太大导致单次写入耗时过长
- 目标库自身延迟：主从复制延迟、GC 停顿、缓存失效
我的建议：写入延迟的监控粒度要细到「单批次写入耗时」。如果发现单批次写入耗时超过 500ms，就要检查目标库的健康状态了。
四个指标的关系：一张图看懂
说了这么多，你可能有点晕。这四个指标到底怎么关联的？我画了一张图，帮你理清思路。
如何设置合理的阈值？
阈值设得太松，延迟大了才发现不了。设得太紧，告警满天飞，运维团队会麻木。我个人的经验是：
- 端到端延迟：以业务 SLA 为准。业务要求 5 秒内同步，阈值就设 4 秒，留 1 秒余量。
- 解析延迟：不超过端到端阈值的 50%。如果端到端阈值是 4 秒，解析延迟超过 2 秒就告警。
- 传输延迟：以网络基线为准。先跑一周收集数据，取 P99 值的 1.5 倍作为阈值。
- 写入延迟：不超过端到端阈值的 30%。写入端往往是瓶颈，要留足余量。
曾经踩过的坑：有一次我把传输延迟阈值设成了固定值 500ms。结果某天网络正常波动到 600ms，告警刷屏了。后来改成动态基线 + 百分比阈值，才消停。记住，阈值要动态调整，别死脑筋用固定值。
小结
延迟监控不是看一个数字就完事了。你得把延迟拆开，看每一段。解析延迟看源库和解析器，传输延迟看网络，写入延迟看目标库。端到端延迟是结果，分段延迟是原因。