本文主要是介绍【bug排查解决】现象级延迟8-10s，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
业务背景
最近公司在做物联网相关的项目，调试过程中发现好玩的bug。
首先一个数据采集场景，plc采集数据全链路：
kepServer（kepserver IOT gateway） -> emqx （查看日志）-> iot服务 -> 业务处理发送Kafka -> flink消费 -> websocket推送告警...
【整个链路还是比较长的】
整个过程是这样的，
kepServer。kepServer上配置设备需要采集的plc数据点位，kepServer自带的IOT gateway，可以针对任意配置点位推送至EMQX服务器topic以及点位推送速率，为了调试配置了几个点位有虚拟点位和真实点位EMQX。启动EMQX：MQTT服务器（业内比较常用的MQTT服务器）IOT服务。 kepServer IOT配置点位数据发生变化后，将数据推送给EMQX，IOT服务监听对应topic解析组装数据直接将消息推送至Kafka。kafka。Kafka为所有类型数据的入口，所有类型数据统一推送至Kafka，如ModBus、MQTT、HttpApi…Flink服务。Flink服务实时消费Kafka数据，根据IOT服务中配置与kepServer上对应的点位以及针对不同点位配置的告警模板，根据阈值或者状态等其他规则实时处理数据。WebSocket。目前Flink集成WebSocket，根据阈值实时推送给前端，实时展示数据，如传感器温湿度、设备状态…
现象
调试真实点位
率先发现改变设备运行状态plc点位值，设备运行状态或者告警产生比较慢【延迟比较多】
分析
查看现有日志，初步分析发现消息生产到推送到Kafka有10s延迟
初步分析：
- kepserver 消息产生有时间
- emqx可以配置日志级别为 debug，查看接受到消息的时间 延迟没问题
- 发送Kafka之前的逻辑比较简单，不会有延迟
最终定位问题IOT接受消息有延迟，IOT框架内Listener监听消息有延迟 orz（初步定位，实际上是错的）
后续，又将IOT监听MQTT消息初打日志，发送Kafka消息耗时时间打印。
对比多个关键节点时间，发现两个延迟点：
- kepServer数据发生变化的时间和EMQX接收到kepServer推送的消息的时间对比：发现有个5-8s的延迟【
kepServer->EMQX】 - Kafka发送消息到成功回调：有个固定2s左右的延迟【
Kafka】
发现问题比解决问题更难，多打日志，好定位问题，养成习惯
最终解决
全链路排查
-
kepServer-
kepServer IOT gateway -> rate 速率设置，由10000 -> 1000
-
这个参数改为1000之后呢（kepServer延迟得到解决），原本8-10s的延迟，变为了3s延迟左右
-
-
kafka-
通过代码中各个关键节点打的日志，发现Kafka发消息到成功回调基本稳定在2s延迟左右，偶尔会有基本无延迟的情况（这种情况有点意思）
-
各种查资料发现Kafka有如下几个与
消息缓存区相关的参数kafka:...producer:batch-size: 16384 # kafka本地线程会去缓冲区中⼀次拉16k的数据，发送到brokerbuffer-memory: 33554432 # 消息缓冲区默认32m...properties:linger:ms: 10 # 默认 10ms如果线程拉不到16k的数据，间隔10ms也会将已拉到的数据发到broker
原本这个时间参数刚好设置的就是2000ms(
kafka.producer.properties.linger.ms)，与上述刚好固定两秒延迟相符，偶尔有无延迟现象说明该消息刚发送就到了2s的频次直接就发生了无延迟该时间参数不设置或者设置小一些对延迟有明显的提升，但这样就会频繁发送消息增大网络开销，自行根据业务取舍- 整个默认10ms吧
-
所有都改完之后，基本延迟在1s左右，由于链路本身就比较长，这个时间还是可以接受的。yes
这篇关于【bug排查解决】现象级延迟8-10s的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
