4. 网络与传输排查

CDC 延迟走到网络传输这一层，很多人的第一反应是「加带宽」。但说实话，我见过太多加了带宽延迟反而更诡异的案例。网络传输不是一根水管那么简单，它涉及三个独立但又互相拉扯的环节：带宽够不够用、网络稳不稳定、数据打包合不合理。任何一个环节出问题，消费端看到的延迟都会飙升。

这一章我们就逐个拆开来看。我会结合自己踩过的坑，把排查思路和工具用法说清楚。

4.1 网络带宽瓶颈：你真的用满了，还是被限速了？

带宽瓶颈是最直观的延迟来源。但「带宽不够」和「带宽用不满」是两回事。我遇到过好几次，业务方说带宽是 10Gbps，结果 CDC 延迟还是很大。一查，实际吞吐只有 200Mbps。为什么？

• TCP 窗口太小：发送方还没填满管道就被迫等待 ACK。
• 小包太多：CDC 传输的每条变更记录可能只有几百字节，但 TCP/IP 头部开销占比极高。
• 中间设备限速：云厂商的虚拟交换机、安全组、NAT 网关都有隐性限速策略。

我个人习惯在部署 CDC 管道之前，先跑一轮 iperf3 -c 消费端IP -t 30 -P 4。如果实测吞吐远低于理论带宽，那就不是加带宽能解决的，得先找中间瓶颈。

4.2 网络抖动与重试机制：延迟的隐形放大器

网络抖动（Jitter）比固定延迟更可怕。固定延迟 50ms，CDC 管道可以通过缓冲和预取来适应。但抖动从 5ms 跳到 500ms，TCP 的拥塞控制算法会立刻收缩窗口，重传机制也会被频繁触发。

我曾经在一个跨洲 CDC 项目里遇到诡异现象：平时延迟 200ms，每 10 分钟突然跳到 3 秒。查了半个月，最后发现是运营商的路由策略在固定周期内切换链路，导致丢包率瞬间飙升到 5%。

我的建议是：

• 给 CDC 连接设置合理的超时阈值（例如 10 秒），超过阈值直接报错，而不是无限重试。
• 在消费端实现幂等处理，这样即使上游重试导致重复数据，也不会影响业务。
• 监控 TCP 重传率（netstat -s | grep retrans），如果重传率超过 0.5%，说明网络质量已经影响 CDC 延迟了。

4.3 数据序列化与反序列化开销：被忽视的 CPU 杀手

很多人觉得序列化就是「把对象转成字节流」，能有多慢？嗯，我以前也这么想，直到有一次在压测环境里发现，序列化/反序列化占了 CDC 管道总延迟的 40%。

序列化开销主要来自三个方面：

因素	影响	典型场景
序列化格式选择	JSON 比 Avro 慢 3-5 倍，比 Protobuf 慢 5-8 倍	CDC 输出到 Kafka 时使用 JSON 序列化
数据 Schema 复杂度	嵌套结构、大字段（如 TEXT/BLOB）会显著增加 CPU 消耗	MySQL binlog 中包含大 JSON 列
反序列化频率	消费端每处理一条记录都要反序列化一次	Flink/Spark 消费 Kafka 中的 CDC 事件

我曾经帮一个团队优化 CDC 管道，他们用 JSON 传输 MySQL binlog，每条记录包含 50 个字段，其中 3 个是 TEXT 类型。序列化后的消息体平均 12KB。换成 Avro 并裁剪到 15 个字段后，消息体降到 2KB，CPU 使用率从 85% 降到 30%，端到端延迟从 800ms 降到 120ms。

4.4 网络传输排查的完整流程

把上面三个环节串起来，我总结了一套排查流程。每次遇到 CDC 延迟问题，我都会按这个顺序走一遍：

1. 先确认带宽是否真的够用：用 iperf3 测端到端吞吐，对比 CDC 实际流量。
2. 再检查网络质量：用 mtr 或 ping 持续监控延迟、抖动和丢包率。
3. 然后看序列化开销：在源端和消费端分别 profile CPU，确认序列化/反序列化是否成为热点。
4. 最后调整重试策略：根据网络抖动幅度，设置合理的超时和重试次数。