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
