Kafka 消息不能正常消费问题排查

订单宽表数据不同步

事情的起因是专员在 ze app 上查不到订单了,而订单数据是从 mysql 的 order_search_info 查询的,order_search_info 表的数据是从 oracel 的 BZ_ORDER_INFO 表同步过来的,查不到说明同步有问题

首先重启,同步数据,问题解决,然后查找原因。首先看日志,有如下两种情况

有的容器消费消息的日志正常打印

有的容器很长时间没有消费消息的日志(看着像是消息丢失,福华找dba确认后明确发送没问题,只能是消费的问题)

接着看容器的状况


查看了应用重启前各个容器的 CPU 和内存情况,发现并不均匀,有如下三种情况

  1. CPU一直很高(内存稳定)
  2. CPU和内存一直稳定上升
  3. CPU一直很低(内存稳定)

看监控发现消息在分区中分布的也不均衡

接着就按照如下现象来进行排查问题

  1. 为什么消息发送不均衡
  2. 为什么有的容器CPU一直很高,有的一直很低,有的持续升高(CPU飙高的机器,内存也不断上涨)

为什么会出现这些现象

producer发送消息和consumer消费消息都有对应的负载均衡策略,既然消息发送不均衡,只需要看producer的负载均衡策略即可

producer的负载均衡实现类为 DefaultPartitioner,具体实现为

  1. 如果 key 为 null:消息将以轮询的方式,在所有可用分区中分别写入消息
  2. 如果 key 不为 null:对 Key 值进行 Hash 计算,从所有分区中根据 Key 的 Hash 值计算出一个分区号;拥有相同 Key 值的消息被写入同一个分区;

所以推测 hddp-datasync 消费的消息指定了key,看消费日志确定了猜想,key的名字为表名,例如

HLASSET.BZ_ROOMCONFIG_DETAIL

HLASSET.BZ_ORDER_INFO

这样就明确了,同一张表的数据只会被发送到同一个分区,同一个分区的数据只能被一个 Consumer 消费

接着我们查到 CPU 一直比较高的容器,消费的是合同表的数据,合同表的数据变更比较频繁,所以CPU比较高

而 CPU 持续飙升的容器,消费的是订单表的数据。

接着就是排查消费订单表的容器为什么CPU和内存持续飙升

排查内存泄漏

一般使用 Eclipse Memory Analyzer 分析内存泄漏的问题,先生成 dump 文件

点击 Leak Supects 查看内存泄漏分析

总共使用了110MB内存,Thread线程占用了29M,总共创建了2686个线程,看一下这些线程是哪些?

线程数量最多的线程名字为datasync-execuotr-1,到代码中查看是否有类似线程

每消费一次订单表的数据,就会新创建一个线程池,核心线程数为10,不断创建线程导致内存和CPU不断飙升,消息不能正常消费,后续消费消息改成使用一个固定的现成池后,消息正常消费

相关推荐
半新半旧28 分钟前
Redis集群和 zookeeper 实现分布式锁的优势和劣势
redis·分布式·zookeeper
亲爱的非洲野猪1 小时前
Kafka “假死“现象深度解析与解决方案
分布式·kafka
虾条_花吹雪1 小时前
2、Connecting to Kafka
分布式·ai·kafka
Edingbrugh.南空3 小时前
Hadoop高可用集群搭建
大数据·hadoop·分布式
Bug退退退1233 小时前
RabbitMQ 高级特性之重试机制
java·分布式·spring·rabbitmq
在肯德基吃麻辣烫5 小时前
《Redis》缓存与分布式锁
redis·分布式·缓存
亲爱的非洲野猪5 小时前
Kafka消息积压全面解决方案:从应急处理到系统优化
分布式·kafka
掘金-我是哪吒5 小时前
分布式微服务系统架构第157集:JavaPlus技术文档平台日更-Java多线程编程技巧
java·分布式·微服务·云原生·架构
掘金-我是哪吒6 小时前
分布式微服务系统架构第155集:JavaPlus技术文档平台日更-Java线程池实现原理
java·分布式·微服务·云原生·架构
Bug退退退12315 小时前
RabbitMQ 高级特性之死信队列
java·分布式·spring·rabbitmq