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的应用，如果生产者失败，消费者将得不到新的消息。

Broker指标

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

Consumer指标

consumer是kafka消息终点

zookeeper指标

zookeeper是kafka的一个关键组件（v3.0）之前，zookeeper停机将使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

链接：https://blog.51cto.com/u_11555417/6177911

（版权归原作者所有，侵删）