Flink使用BroadcastProcessFunction后出现固定60秒处理延迟排查求助

可能原因 #

• 规则初始化耗时过高：自定义HTTP规则Source首次调用规则接口的耗时刚好为60秒，作业启动后到第一次拉取到规则的这段时间内，所有流入的业务事件都会被算子缓存，直到第一条广播规则写入状态后才会批量处理缓存的事件，直观表现就是每个事件的处理延迟刚好为60秒。
• 水印推进阻塞：你配置了作业的时间特征为IngestionTime，但自定义的规则Source没有生成、发射水印，双流连接场景下作业的全局水印会被没有水印输出的规则流卡住，如果你业务逻辑中存在依赖水印的操作，就会出现固定延迟。
• 空状态逻辑异常：当前processElement的实现中没有对广播状态做非空判断，作业刚启动广播状态为空时，调用rulesEvent.getRules()会抛出空指针，如果你配置了全局异常重试策略且重试间隔为60秒，也会出现该现象。
• 缓冲区配置异常：如果作业的execution.buffer-timeout参数被手动设置为60000ms，Flink会攒够60秒的数据才向下游算子发送，也会产生固定延迟。

解决方案 #

• 在规则Source的open方法中新增一次规则预拉取逻辑，确保作业启动后广播状态立刻有初始值，避免业务事件长时间缓存。
• 若业务逻辑完全不需要时间语义，可以将时间特征改为ProcessingTime，避免水印阻塞问题；如果需要保留IngestionTime，要在规则Source中补充水印发射逻辑。
• 在processElement中新增广播状态非空判断，状态为空时可根据业务需要选择侧流输出暂存事件、暂时丢弃事件等逻辑，避免空指针异常。
• 在规则接口调用逻辑中增加耗时埋点和超时控制，排查是否存在接口响应慢的问题。
• 检查作业的execution.buffer-timeout配置，确认是否被误设为60000ms，改回默认的1000ms即可。

内容的提问来源于stack exchange，提问作者Ben Nelson