kafka中常见问题你遇到哪些

描述

kafka核心概念

kafka

Broker: 一个kafka服务端节点

cluseter: 集群,由多个Broker组合的集合

message:消息,也叫Record,kafka中信息传递的载体,对于kafka

Producer:生产者,向kafka发送消息的应用

Consumer:消费者,从kafka接收消息的应用

Consumer Group:消费者组,一组具有相同Group ID的Consumer,当一个topic被同一个group的多个consumer消费的时候,每条消息都只会投递到一个Consumer,实现消费的负载均衡,通过group,可以确保一个topic消息被并行消费,调高吞吐量

Topic:消费的主题,用于分类消息,在每个Broker上都可以创建多个topic

Replica:副本,每一个分区都有多个副本,当主分区故障的时候会选择一个备分区,成为leader,kafka中默认副本最大数量是10,副本的数量不能大于broker的数量

Partition:分区,一个有序不变的消息列队,用于存储消息,一个topic由一个或者多个分区组成,每个分区中的消息存储于一个或者多个broker上,在一个分区中消息的顺序就是producer发送消息的顺序。

offset: 分区中每条消息位置的信息,是一个单调递增且不变的值。

消费位点:分区被当前consumer消费了消息的最大位点

堆积量:当前分区下消息堆积的总量,即最大位点减去消费位点的值。堆积是一个关键指标,如果发现堆积量较大,则comsumer可能出现了阻塞,或者消费速度更不上生产的速度,此时需要分析consumer的运行状况,尽力提升消费速度。可以清除所有的堆积消息,从最大位点开始消费,或者按照时间点进行点重置。

rebalance:重平衡,消费组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅的主题分区的过程,它是kafka消费者端实现高可用的重要手段。

zookeeper: kafka集群依赖zookeeper来保存集群的元信息,以保证系统的可用性。

kafka版本

0.1x 早期孵化版本

1.x 优化streams API,增强可观测性和可调试性,支持java9,优化SASL

2.X 性能提升,增强acl支持

3.x 去掉zookeeper依赖,支持java17,不再支持java8,不再支持v0和v1消息,性能大幅提升

推荐使用2,x和3.x版本

Kafka Metric监控

Producer指标

生产者将消息推送到Broker Topic的应用,如果生产者失败,消费者将得不到新的消息。

kafka

Broker指标

因为所有的消息必须通过kafka broker才能被使用,所以对集群中Broker的监控是最核心。

kafka

kafka

kafka

Consumer指标

consumer是kafka消息终点

kafka

zookeeper指标

zookeeper是kafka的一个关键组件(v3.0)之前,zookeeper停机将使kafka停止运行。

kafka

kafka典型问题和排查

topic消息发送慢,并发性能低

某个或者某几个Topic的消息并发发送性能低,在指标上体现为producer的平均请求延迟大,平均生产吞吐量小

通常消息发送慢如下几种典型原因:

网络带宽不足,导致IO等待

消息未压缩,导致网络流量超负荷

消息未批量发送,或者批量阈值配置不恰当,导致发送速率慢

topic分区数量不足,导致broker接收消息积压

broker磁盘性能低,导致磁盘同步慢

broker分区总量过多,导致碎片化,磁盘读写过载‘

排查

确认producer的平均IO等待时间指标是否符合预期或者陡增,以便producer到broker之间的网络带宽是否满足业务的流量要求

确认producer的平均压缩率指标,确保要压缩率符合预期

确认producer的平均请求包大小是否过小,如果是的化,需要考虑增大producer发送消息的batchsize,同时调整linger.ms的阈值

查看topic分区数量,分区较小的时候,考虑增加分区数,以水平扩展broker的并发接收消息容量

确认borker磁盘IO使用率是否在安全范围之内,如果使用率已经较高,则考虑垂直或者水平扩容Broker,同时考虑增加topic分区数,提升topic并接收消息能力

查看集群的总分区数和单个boker的分区数量,确保在规划的容量范围之内。

topic消息堆积

某个或者几个topic的消息堆积持续增加,在指标上直接体现为group消费延迟数量持续增加

常见的消息堆积有如下几种原因:

producer生产消息流量增大

consumer由于业务变化导致消费延迟增加

consumer数量不足

consumer数量频繁变化,导致group不断做再平衡rebalance

broker未收到consumer消息确认消息

排查

确认producer的消息生产量指标是否明显增加

确认consumer的消息流量指标是否明显下降

通过kafka broker提供的命令,确认topic对应consumer数量与实际的consumer数量是否一致,如果不一致,说明某些consumer未正确连接到broker,需要排查consumer是否正常运行

观察consumer的数量是否频繁变化而触发犯法再平衡

由于网络或者其他原因,可能导致consumer与boker之间的连接不稳定,consumer能持续消费消息,但是broker却始终认为消息未确认,导致消费位点不变,此时可能需要确认consumer与broker之间的网络稳定性,甚至重启consumer

审核编辑:黄飞

 

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分