实时链路延迟怎么排查

难度与前置

难度：中级
前置：会看 Kafka lag、Flink UI；知道事件时间与处理时间的区别。
读完能做什么：把端到端延迟拆段，只优最贵一段，并用 P95 前后数字验收。

适用场景

实时看板 / 接口延迟升高，不确定慢在采集、消息、计算、存储还是服务。

不适用：单机本地调试小作业；离线 T+1 变慢（走批排查文）。

真实场景（一条）

投放实时消耗看板：端到端约 10 分钟（业务 SLA 60 秒）。

分段实测（示例量级）：

段	改前耗时贡献	结论
采集→Kafka	~2s	正常
Kafka 消费 lag	~30s	可接受
Flink 处理	算子正常，sink 反压	嫌疑
OLAP 可见	写入排队 ~8 分钟	最贵段
API 查询	~200ms	正常

动作：sink 批量写入 + 连接池扩容。改后端到端 P95 ≈ 25s，OLAP 写入排队 < 10s。

怎么做（步骤清单）

1. 画链路并约定时间戳

采集/埋点 → Kafka → Flink/作业 → OLAP/仓 → API/看板

尽量每段有可查时间：

• event_ts：业务事件时间
• ingest_ts：入 Kafka / 入仓时间
• process_ts：计算输出时间
• visible_ts：查询侧可见时间

端到端延迟：visible_ts - event_ts（或产品约定的口径，写死一种）。

2. 五分钟分段取样（可照做）

同一时间窗（如最近 15 分钟）平行记录：

A. Kafka：kafka-consumer-groups --describe → 总 lag、最大分区 lag
B. Flink：UI BackPressure 色块、瓶颈算子 busy、Checkpoint Duration
C. 存储：写入 QPS、队列长度、P99 写 RT、失败重试
D. API：慢查询 P95、缓存命中率
E. 抽样 20 条事件：列出 event_ts → visible_ts 差值

把「最贵段」圈出来，只改这一段。

3. 分段处置指针

最贵段	去哪篇 / 做什么
Kafka	积压排查
计算反压	反压排查
Checkpoint / 一致性	Checkpoint 与 Failover
存储写入	批量、限流、扩连接、查主键冲突重试
API	慢 SQL、索引、缓存；与实时链路解耦

4. 改完只复测两样

1. 端到端 P95 / P99
2. 刚才最贵段的核心指标（如写排队、反压比、lag）

未变好 → 回滚该类改动，重新取样，避免多旋钮一起拧。

5. 正确性边界

延迟优化不得默认丢掉迟到数据。水位线、允许迟到、侧输出策略要业务签字，并写进验收。

常见坑（至少这些）

1. 只盯 Flink，不盯 OLAP 写入队列
   UI 算子很绿，看板仍晚十分钟。

2. 用处理时间冒充事件时间
   「看起来实时」，跨时区 / 乱序一来口径全错。

3. 多段同时改参
   Kafka、Flink、DB 一起调，无法归因，也不敢回滚。

4. lag 降了就宣布胜利
   消费变快但写库失败重试，可见时间反而更差。

5. 为降延迟关掉 Checkpoint 或随意放水
   故障后重复/丢数，比延迟更贵。

6. 抽样只用「成功写入」的事件
   忽略堆积在失败队列里的真实延迟。

如何验收（带数字的前后对比）

指标	改前	改后	目标示例
端到端 P95	如 10 min	如 25 s	≤ 60 s
端到端 P99	如 18 min	如 45 s	≤ 120 s
最贵段指标	如写排队 8 min	如 < 10 s	按段自定
Kafka 总 lag	（若相关）		回水位
抽样 20 条最大延迟			无异常长尾

Checklist：

• [ ] 五段取样表已归档（改前/改后）
• [ ] 只优化并验证了最贵段
• [ ] 迟到数据策略未默默丢弃
• [ ] 与离线对账差额在约定范围（如消耗日汇总 diff < 0.5%）
• [ ] 连续两个高峰时段 P95 仍达标

验收记录模板：
时间窗：
端到端 P95 改前 → 改后：
最贵段：采集 / Kafka / Flink / 存储 / API
改动（仅一类）：
最贵段指标改前 → 改后：
对账 diff：
签字：

相关面试题

占位：实时链路怎么设计；延迟怎么排查。

---

改写说明：审校通过后的补厚定稿；无未公开公司数据。