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

发布时间:2024年01月17日

订单宽表数据不同步

事情的起因是专员在 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 文件

李立敏 > hddp-datasync 消息不同步问题排查 > image2022-10-10_20-42-27.png

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

在这里插入图片描述

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

文章来源:https://blog.csdn.net/zzti_erlie/article/details/135062967
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。