【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance

这篇具有很好参考价值的文章主要介绍了【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

最近有点不走运,老是遇到基础服务的问题,还是记着点儿解决方法,以后再遇到快速解决吧,今天遇到这个问题倒不算紧急,但也能通过这个问题熟悉一下Kafka的配置。

问题背景

正在开会的时候突然收到一连串的报警,赶忙看看是为啥
【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance,工作中问题解决实践,kafka,分布式
没过一会儿基础服务报警也来了

告警名称:Kafka-topic consume exception
识别号:xxxxx
状态:firing 
开始时间:2023-08-09 19:28:05
当前时间:2023-08-09 19:28:05
SummaryKafka Cluster: common-xxxx-xx Topic: { xxxxxxx-prod } Group:xxxxxxx-prod Status: STALL
Description: 诊断报告

报警标识

Kafka 自身的异常状态的枚举:

  1. Leader Not Available (LEADER_NOT_AVAILABLE): 当尝试读取或写入一个分区时,分区的 Leader 副本不可用。
  2. Replica Not Available (REPLICA_NOT_AVAILABLE): 当尝试读取或写入一个分区时,分区的副本不可用。
  3. Request Timeout (REQUEST_TIMED_OUT): 请求在指定的时间内没有得到响应,可能是因为网络延迟、负载过重等原因。
  4. Offset Out of Range (OFFSET_OUT_OF_RANGE): 尝试读取一个不存在的偏移量。
  5. Invalid Offset (INVALID_OFFSET): 提供了无效的偏移量。
  6. Unknown Topic or Partition (UNKNOWN_TOPIC_OR_PARTITION): 尝试访问不存在的主题或分区。
  7. Record Too Large (RECORD_TOO_LARGE): 尝试写入的记录大小超过了 broker 配置的最大记录大小。
  8. Not Enough Replicas (NOT_ENOUGH_REPLICAS): 写入操作无法满足分区的最小副本数配置。
  9. Message Size Too Large (MESSAGE_TOO_LARGE): 尝试写入的消息大小超过了 broker 配置的最大消息大小。
  10. Topic Authorization Failed (TOPIC_AUTHORIZATION_FAILED): 消费者或生产者没有足够的权限来访问指定的主题。
  11. Group Authorization Failed (GROUP_AUTHORIZATION_FAILED): 消费者群组没有足够的权限来访问指定的群组。
  12. Offset Metadata Too Large (OFFSET_METADATA_TOO_LARGE): 提供的偏移量元数据超过了 broker 配置的最大大小。
  13. Connection Error (CONNECTION_ERROR): 与 broker 的连接遇到问题,可能是网络故障或 broker 宕机等原因。
  14. Unknown Error (UNKNOWN_ERROR): 未知的错误,可能是由于 Kafka 内部问题引起的。

这些异常状态可以在 Kafka 的客户端和服务端之间的交互中出现,通常会在日志或异常堆栈跟踪中得到体现

基于Kafka-topic_consume_exception策略,一般对于分区状态的依据kafka的报警状态枚举:

  1. NotFound 状态:这个consumer group 不存在
  2. OK 状态:正常消费
  3. Warning 状态:有一个或多个分区正在延迟,当前在消费,但是消费延迟越来越大
  4. Error 状态:有一个或多个分区已经处于STOP,STALL,Rewind等几种状态之一
  5. Stop 状态:消费者已经有一段时间没有提交offset了,并且消费延迟非0
  6. Stall 状态:消费者正在提交offset,但是offset没有增加,并且消费延迟非0
  7. Rewind 状态:消费者提交了一个比之前还早的offset

ok,Stall状态结合监控异常,我们发现应该是一批次提交的数量太多处理不完了,可以通过增加批次处理间隔或减少批次数量避免延迟消费

问题原因

配置举例: max.poll.records = 20,而 max.poll.interval.ms = 1000,也就是说consumer一次最多拉取 20 条消息,两次拉取的最长时间间隔为 1 秒。也就是说消费者拉取的20条消息必须在1秒内处理完成,紧接着拉取下一批消息。否则,超过1秒后,kafka broker会认为该消费者处理太缓慢而将他踢出消费组,从而导致消费组rebalance。根据kafka机制,消费组rebalance过程中是不会消费消息的。所以看到三台机器轮流拉取消息,又轮流被踢出消费组,消费组循环进行rebalance,消费就堆积了

标准指标

生产者的一些参数指标
【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance,工作中问题解决实践,kafka,分布式
消费者的一些参数指标
【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance,工作中问题解决实践,kafka,分布式

问题解决

明确问题原因后,很好解决,把一批的最大拉取数量调小即可:spring.kafka.consumer.max-poll-records,比默认值500多小一点,调整完配置上线后就解决了,消费延迟很快降低到0了
【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance,工作中问题解决实践,kafka,分布式

总结一下

照例总结一下,虽然基础服务的一些中间件一般都由基础架构部门维护,但还是要对这些中间件的配置和使用要有所了解,这样出了问题才能快速定位问题、解决问题,避免影响线上稳定性文章来源地址https://www.toymoban.com/news/detail-648034.html

到了这里,关于【工作中问题解决实践 十一】Kafka消费者消费堆积且频繁rebalance的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Kafka每日一问】Kafka消费者故障,出现活锁问题如何解决?

    在Kafka中,消费者的“活锁”通常是指消费者实例持续失败并重新加入消费者组,但却始终无法成功处理消息。这种现象可能会导致消费者组不断触发重平衡(rebalance),而消息却没有被实际消费。以下是一些解决或缓解活锁问题的策略: 1. 优化消息处理逻辑 消费者可能由于

    2024年01月20日
    浏览(44)
  • Kafka入门, 消费者工作流程

    pull(拉)模式: consumer采用从broker中主动拉取数据。 Kafka采用这种方式。 push(推)模式: Kafka没有采用这种方式,因为由broker决定消息发送速率,很难适应所有消费者的速率。例如推送速度是50m/s,consumer1,consumer2就来不及处理消息 pull模式不足之处是,如果kafka没有数据,消费者

    2024年02月12日
    浏览(35)
  • Kafka入门, 消费者工作流程(十八)

    pull(拉)模式: consumer采用从broker中主动拉取数据。 Kafka采用这种方式。 push(推)模式: Kafka没有采用这种方式,因为由broker决定消息发送速率,很难适应所有消费者的速率。例如推送速度是50m/s,consumer1,consumer2就来不及处理消息 pull模式不足之处是,如果kafka没有数据,消费者

    2024年02月13日
    浏览(67)
  • Kafka及Kafka消费者的消费问题及线程问题

    Topic:是 Kafka 消息发布和订阅的基本单元,同时也是消息的容器。Topic 中的消息被分割成多个分区进行存储和处理。 Partition:是 Topic 分区,将 Topic 细分成多个分区,每个分区可以独立地存储在不同的 Broker 中,从而增加了消息的并发性、可扩展性和吞吐量。 Broker:是 Kafka

    2024年02月14日
    浏览(40)
  • Kafka消费者无法消费数据,解决

    作为一个在项目中边学边用的实习生,真的被昨天还好好的今天就不能消费数据的kafka折磨到了,下面提供一点建议,希望能对大家有所帮助。 //操作前集群都关了 1.首先去kafka-home的config目录下找到server.properties文件, 加入advertised.listeners=PLAINTEXT://ip:9092    如果有配置liste

    2024年02月17日
    浏览(50)
  • kafka实战-消费者offset重置问题

    背景:当app启动时,会调用 “启动上报接口” 上报启动数据,该数据包含且不限于手机型号、应用版本、app类型、启动时间等,一站式接入平台系统会记录该数据。 生产者:“启动上报接口”会根据启动数据发送一条kafka消息,topic“xxx” 消费者:“启动处理模块”会监控

    2023年04月11日
    浏览(86)
  • 【云原生进阶之PaaS中间件】第三章Kafka-4.4-消费者工作流程

    1.1.1 消费者群组         Kafka 里消费者从属于消费者群组,一个群组里的消费者订阅的都是同一个主题,每个消费者接收主题一部分分区的消息。         如上图,主题 T 有 4 个分区,群组中只有一个消费者,则该消费者将收到主题 T1 全部 4 个分区的消息。      

    2024年02月22日
    浏览(48)
  • Spring Boot中使用Kafka时遇到“构建Kafka消费者失败“的问题

    在使用Spring Boot开发应用程序时,集成Apache Kafka作为消息队列是一种常见的做法。然而,有时候在配置和使用Kafka时可能会遇到一些问题。本文将探讨在Spring Boot应用程序中使用Kafka时可能遇到的\\\"构建Kafka消费者失败\\\"错误,并提供解决方案。 错误描述: 当尝试构建Kafka消费者时

    2024年01月17日
    浏览(46)
  • kafka消费者程序日志报错Offset commit failed问题研究

    生产环境偶尔会遇到kafka消费者程序日志报错的问题 截取主要日志如下: kafka客户端版本为2.2.0 结合日志去阅读代码,只能大概定位到,是客户端程序向server发送commit offset请求的时候,server返回的错误信息是:The request timed out 看到 request timed out,第一时间很可能会误以为是

    2024年02月07日
    浏览(51)
  • Kafka系列之:记录一次Kafka Topic分区扩容,但是下游flink消费者没有自动消费新的分区的解决方法

    生产环境Kafka集群压力大,Topic读写压力大,消费的lag比较大,因此通过扩容Topic的分区,增大Topic的读写性能 理论上下游消费者应该能够自动消费到新的分区,例如flume消费到了新的分区,但是实际情况是存在flink消费者没有消费到新的分区 出现无法消费topic新的分区这种情况

    2024年02月14日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包