面对Kafka消费不给力,如何轻松解决呢?

本文探讨了在使用Kafka作为消息中间件时遇到的消费问题,包括Consumer宕机和分区不合理导致的消息积压。提出了针对性的解决方案,如任务重启策略、合理设置分区数、避免数据不均衡等,同时强调了在消费速度不一致时offset提交的处理问题。
摘要由CSDN通过智能技术生成

我是架构精进之路,点击上方“关注”,坚持每天为你分享技术干货,私信我回复“01”,送你一份程序员成长进阶大礼包。   

一、背景

随着目前业务复杂度的增加,项目中经常需要有大量的跨系统异步任务需要处理。

在这种情况下, 我们选择了kafka作为了我们的消息中间件, 选择kafka主要基于以下几点:

  • 支持分布式,避免单点问题

  • 技术方案成熟,公司内部有上线项目

  • 性能优异,能够持久化消息

通常情况下,我们会采取轮询或者随机的方式,通过Kafka的producer向Kafka集群生产数据,来尽可能保证Kafk分区之间的数据是均匀分布的。

在分区数据均匀分布的前提下,如果我们针对要处理的topic数据量等因素,设计出合理的Kafka分区数量。对于一些实时任务,比如Spark Streaming/Structured-Streaming、Flink和Kafka集成的应用,消费端不存在长时间"挂掉"的情况即数据一直在持续被消费,那么一般不会产生Kafka数据积压的情况。

但是这些都是有前提的,当一些意外或者不合理的分区数设置情况的发生,积压问题就不可避免。

二、遇到的问题及剖析

问题描述

第一次发现问题是在联调的时候,任务执行方发现consumer会打印出错误日志,重复消费,并且陷入循环。

当时很

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

架构精进之路

觉得不错可以请作者喝杯茶

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值