Shell控监Kafka积压

1、获取Kafka消息堆积情况

vi check-kafka-lag.sh

#!/bin/bash

TOPIC="total_random"
GROUP_ID="etl-dw"
BOOTSTRAP_SERVER="node-01:9092,node-02:9092,node-03:9092"

# 检查第一个参数是否为数字
if ! [[ $1 =~ ^[0-9]+$ ]]; then
    echo "错误: 传入参数必须是数字" >&2
    exit 1
fi

# 获取LAG信息
LAG_INFO=`sh /data/app/kafka/bin/kafka-consumer-groups.sh --bootstrap-server $BOOTSTRAP_SERVER --group $GROUP_ID --describe | grep $TOPIC | awk -F " " '{print $6}'`

# 初始化LAG总和为0
total_lag=0

for lag in ${$LAG_INFO[@]};
do
  total_lag=$(($total_lag + $lag))
done

# 判断消息积压情况,是否重启程序
if [ $total_lag -gt $1 ]; then 
  echo "$(date +"%Y-%m-%d %H:%M:%S") Kafka Topic " $TOPIC " IN GROUP " $GROUP_ID " 消息堆积总量为:" $total_lag " 大于 " $1 ",停止DW模块"
  sh ./stop-dwkudu.sh
  
  # 判断是否执行成功
  if [ $? -eq 0 ]; then 
    sh ./start-dwkudu.sh
	echo "$(date +"%Y-%m-%d %H:%M:%S") 启动DW模块完成"
  else
    echo "$(date +"%Y-%m-%d %H:%M:%S") 停止DW模块失败"
  fi

else
  echo "$(date +"%Y-%m-%d %H:%M:%S") Kafka Topic " $TOPIC " IN GROUP " $GROUP_ID " 消息堆积总量为:" $total_lag " 小于 " $1
fi

2、创建定时任务

每隔1小时,执行一次

0 */1 * * * /data/app/etl-dw/shell/check-kafka-lag.sh 100000 >> /data/logs/etl-dw/check-kafka-lag.log 2>&1 &
<think>我们正在处理Kafka中ys-apps主题消息积压500万的问题。消息积压通常是由于消费者处理速度跟不上生产者发送速度导致的。我们将从多个角度分析问题并提供解决方案。参考已有的引用信息:引用[1]提到了消息重复的问题,但我们的问题是消息积压,所以重点不在此,但要注意在解决积压过程中避免引入消息重复。引用[2]提供了kafka-console-consumer.sh的使用示例,我们可以使用这个命令来监控消费情况。引用[3]提到了消息时间戳,我们可以考虑按时间戳处理积压数据,比如跳过旧数据或者加速处理。解决方案思路:1.紧急处理:临时增加消费者实例,提高消费能力。2.定位瓶颈:检查消费者性能,优化消费逻辑。3.扩容:如果资源允许,增加分区和消费者实例。4.跳过非关键数据:如果部分数据可以丢弃,可以考虑跳过旧消息。5.长期优化:优化消费者代码,提高处理效率。具体步骤:步骤1:监控积压情况使用Kafka命令查看积压量:```shellkafka-consumer-groups.sh--bootstrap-server<broker_list>--describe--group<consumer_group_name>```输出中会显示每个分区的LAG(积压量)。步骤2:临时增加消费者实例如果消费者组是同一个,那么增加消费者实例的数量(不能超过分区数)。注意:增加实例前,确保主题的分区数足够,因为一个分区只能被一个消费者实例消费。因此,如果分区数不够,需要先增加分区(但注意分区只能增加不能减少)。步骤3:增加分区(如果必要)如果当前分区数较少,可以增加分区:```shellkafka-topics.sh--bootstrap-server<broker_list>--alter--topicys-apps--partitions<new_partition_count>```注意:增加分区后,需要重启消费者应用或者让消费者重新加入组,才能重新分配分区。同时,增加分区可能会影响消息的顺序性(如果业务依赖顺序,需注意)。步骤4:优化消费者处理逻辑检查消费者代码,是否存在性能瓶颈?例如:-是否每次处理一条消息?考虑批量处理。-是否进行耗时的I/O操作?考虑异步或优化。-是否处理逻辑过于复杂?简化逻辑。步骤5:跳过旧消息(如果允许)如果业务允许丢弃部分旧消息(比如只关心最新数据),可以重置消费者位移到最新位置。但请谨慎操作,因为会丢失数据。```shellkafka-consumer-groups.sh--bootstrap-server<broker_list>--group<consumer_group_name>--reset-offsets--to-latest--topicys-apps--execute```或者重置到某个时间点(引用[3]提到的时间戳):```shellkafka-consumer-groups.sh--bootstrap-server<broker_list>--group<consumer_group_name>--reset-offsets--to-datetime<datetime>--topicys-apps--execute```其中`<datetime>`格式为`YYYY-MM-DDTHH:mm:SS.sss`,例如`2023-01-01T00:00:00.000`。步骤6:提高消费者拉取参数调整消费者参数,如一次拉取更多的数据:-`max.poll.records`:控制一次拉取的最大记录数(默认500,可适当增大)。-`fetch.max.bytes`:一次拉取的最大字节数。-注意:调整参数需要根据消费者处理能力和内存情况。步骤7:使用更高效的消费者客户端考虑使用更高效的客户端库,或者使用多线程消费(注意线程安全)。步骤8:生产者限流(如果可能)如果积压是由于突发流量导致,且生产者可以控制,可以暂时降低生产者的发送速率。步骤9:持久化存储与批量处理如果消费者需要将数据入数据库,考虑批量入,减少数据库入次数。步骤10:监控与告警建立积压监控,当积压超过阈值时告警,以便及时处理。注意事项:-在调整分区和重置位移时,需确保业务允许。-任何操作前最好备份数据或确认有回滚方案。根据以上步骤,我们可以逐步解决消息积压问题。相关问题:1.如何监控Kafka消费者的积压情况?2.增加Kafka主题分区会对现有数据产生什么影响?3.重置消费者位移有哪些风险?4.如何优化Kafka消费者的处理性能?5.Kafka消费者参数调优有哪些关键参数?</think>### Kafka消息积压解决方案 针对`ys-apps`主题积压500万消息的问题,以下是系统级解决方案: #### 1. **紧急扩容消费能力** - **增加消费者实例**:通过水平扩展消费者组实例数量加速消费(不超过分区数) ```shell # 示例:启动新消费者实例 bin/kafka-console-consumer.sh --bootstrap-server node1:9092 \ --topic ys-apps --group your_consumer_group ``` *需确保分区数足够(1个分区仅被1个消费者消费)[^2]* - **扩容分区**(必要时): ```shell bin/kafka-topics.sh --bootstrap-server node1:9092 --alter \ --topic ys-apps --partitions 30 # 建议扩容至当前消费者数的2倍 ``` *注意:分区扩容不可逆,且可能影响消息顺序性* #### 2. **优化消费逻辑** - **批量消费**:修改消费者参数提升吞吐量 ```properties fetch.max.bytes=10485760 # 单次拉取最大10MB max.poll.records=5000 # 单批次处理5000条 max.partition.fetch.bytes=4MB # 每个分区拉取量 ``` - **异步处理**:将消息存入内存队列,由工作线程异步处理 - **跳过非关键数据**(紧急时): ```shell # 重置offset到最新位置(丢弃积压数据) bin/kafka-consumer-groups.sh --reset-offsets --to-latest \ --group your_group --topic ys-apps --execute ``` #### 3. **生产者端限流** ```java // 生产者代码添加限流(示例) props.put("max.in.flight.requests.per.connection", 1); // 防止消息乱序 props.put("linger.ms", 100); // 适当增加批次提交延迟 ``` *通过降低生产速率换取消费端处理时间[^1]* #### 4. **深度监控排查** ```shell # 实时监控积压量 bin/kafka-consumer-groups.sh --describe \ --group your_group --bootstrap-server node1:9092 # 输出示例: TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG ys-apps 0 15234007 15734007 500000 ``` - **关键指标**: - `LAG>10000`:预警阈值 - 消费延迟:`log-end-offset - current-offset` - 处理耗时:对比`消息生产时间戳`与`消费时间戳`[^3] #### 5. **长期优化措施** - **消费者逻辑优化**: - 避免同步DB操作,改用批量入 - 禁用自动提交偏移量(`enable.auto.commit=false`) - **架构改进**: ```mermaid graph LR Producer-->Kafka subgraph 消费集群 Kafka-->Consumer1 Kafka-->Consumer2 Kafka-->ConsumerN end Consumer1-->Redis[(缓存层)] Consumer2-->ES[(Elasticsearch)] ``` *引入中间缓存层解耦实时处理* #### 6. **极端情况处理** 若积压数据可丢弃: ```shell # 按时间戳重置offset(保留最近N小时数据) bin/kafka-consumer-groups.sh --reset-offsets \ --to-datetime 2023-08-01T00:00:00.000 \ --group your_group --topic ys-apps --execute ``` > **关键原则**:优先保证新消息实时处理,积压数据异步补偿。500万消息按10万/秒处理速度需50秒,实际需根据消息大小和硬件能力评估。 --- ### 相关问题 1. 如何精准计算Kafka消费者的实时吞吐量? 2. Kafka分区数量与消费者数量如何科学配比? 3. 消息积压时如何避免消费者重复处理? 4. Kafka消息时间戳有哪些高级应用场景?[^3] 5. 消费者组(consumer group)重平衡会导致哪些问题? [^1]: 生产者重试机制导致消息重复的场景分析 [^2]: kafka-console-consumer.sh的位移控制参数详解 [^3]: 基于消息时间戳的积压数据处理策略
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值