1 kafka 架构
kafka4.0之前的版本架构见Kafka核心原理的秘密，藏在这19张图里 中的kafka的整体结构部分
kafka4.0版本相较于之前版本的区别见Kafka 4.0 发布：KRaft 替代 Zookeeper、新一代重平衡协议、点对点消息模型、移除旧协议 API 中的KRaft 模式的技术实现、新一代消费者重平衡协议、点对点消息模型与共享组三部分
总结：kafka4.0相对与之前版本结构的区别：
- 去掉zookeeper，kafka集群元信息不在通过zookeeper维护，具体看上边的链接；
- 消费者平衡协议引入增量式重平衡协议Kafka–基础知识点–20–消费者平衡协议的增量式重平衡协议；
- 消费者引入共享组，共享组内的消费者多个消费者可以消费同一个分区内的消息。消费者共享组（Share Group）与传统的消费者组（Consumer Group）是两种完全独立且并列的组类型。它们设计用于不同的场景，不能混用或互相操作。
2 生产者架构
kafka–基础知识点–3.1–生产者架构
3 消息的磁盘存储文件结构
kafka–基础知识点–3.2–消息的磁盘存储文件结构
4 ISR、OSR、AR 是什么
kafka–基础知识点–6–AR、ISR、OSR
5 controller实例的选举
kafka4.0之前版本的选举机制小红书一面：Kafka 是如何选择 Leader 的
kafka4.0版本选举机制: pass
6 leader选举机制
kafka4.0之前版本的选举机制小红书一面：Kafka 是如何选择 Leader 的
kafka4.0版本选举机制: pass
7 Kafka创建topic时如何将分区放置到不同的Broker中
- 副本因子不能大于 Broker 的个数；第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；
- 其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
- 剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的；
8 LEO、HW、LW是什么
kafka–基础知识点–6.1–LEO、HW、LW的1、2、3
9 follower 同步leader消息过程 及 leo、hw的变化过程
kafka–基础知识点–6.1–LEO、HW、LW的5
10 leader epoch
kafka–基础知识点–6.3–leader epoch机制
11 LSO是什么
kafka–基础知识点–6.4–LSO
12 produce消息分区策略
kafka–基础知识点–5–生产者分区策略
13 ack 确认策略
kafka–基础知识点–5.1–ACK机制
14 producer幂等性
kafka–基础知识点–5.2–producer幂等性
15 事务
kafka–基础知识点–5.3–事务
16 consumer 分区分配策略
kafka–基础知识点–9–消费者分区分配策略
17 至多一次、最少一次、精确一次
kafka–基础知识点–16–最多一次、至少一次、精确一次
18 如何保证顺序消费
kafka–基础知识点–17–如何保证顺序消费
19 kafka数据保存磁盘 为什么这么快
面试官问：kafka为什么如此之快？
broker收到生产者发送来的消息后：broker将消息缓存到内核的pagecache页缓存[使用了缓存]，然后根据配置的相应刷盘策略将消息刷盘到日志文件[使用了顺序写]。并且broker接收到的一个请求中可以有不同分区的一个batch，一个batch里有一个分区的多条消息[使用了批量操作]
broker收到消费者拉取的请求后：broker将消息从日志文件读取到内核的pagecache页缓存[使用了顺序读]，然后直接从内存的pagecache复制到socket缓存[使用了零拷贝]，并且消费者拉取消息时可以一次拉取多条消息[使用了批量操作]。
并且kafka是多分区的。
20 消息丢失的场景 及 如何避免消息丢失
Kafka消息丢失的3种场景，生产环境千万要注意
其实本质就是消息从生产者到消费者的精确一次的配置及处理方式。
21 消息重复
kafka–基础知识点–19–消息重复
22 消息积压
kafka–基础知识点–18–消息积压
23 kafka为什么不支持读写分离
方便实现单调读（Monotonic Reads）
什么是单调读呢？就是对于一个消费者用户而言，在多次消费消息时，它不会看到某条消息一会儿存在一会儿不存在。
如果允许追随者副本提供读服务，那么假设当前有OSR中的 2 个追随者副本 F1 和 F2，它们异步地拉取领导者副本数据。倘若 F1 拉取了 Leader 的最新消息而 F2 还未及时拉取，那么，此时如果有一个消费者先从 F1 读取消息之后又从 F2 拉取消息，它可能会看到这样的现象：第一次消费时看到的最新消息在第二次消费时不见了，这就不是单调读一致性。但是，如果所有的读请求都是由 Leader 来处理，那么 Kafka 就很容易实现单调读一致性。
24 kafka监控工具
kafka自带工具: 【Kafka】Kafka 提供了哪些系统工具
其它监控工具:
| 工具类别 | 典型代表 | 核心特点与定位 | 适用场景与备注 |
|---|---|---|---|
| 综合商业平台 | Confluent Control Center | Confluent公司官方提供的企业级一体化平台，功能最全面，涵盖监控、管理、告警、流处理可视化。 | 适合追求开箱即用、功能全面且预算充足的企业。与Confluent Platform集成最佳。 |
| 开源Web管理工具 | Kafka Manager (CMAK) | 社区最知名的开源集群管理工具，提供直观的Web界面进行集群、Topic、消费者的基础监控和管理。 | 适合中小规模集群的日常运维，是许多团队的起点。 |
| Kafka-UI | 新兴的轻量级开源Web UI，界面现代，同样支持多集群管理和关键指标跟踪。 | CMAK的现代替代品之一，部署简单。 | |
| 指标监控与可视化套件 | Prometheus + Grafana | 行业标准监控组合。Prometheus抓取并存储时间序列指标，Grafana用于创建丰富的自定义监控仪表盘。 | 绝大多数生产环境的标配，灵活、可扩展，需自行搭建和配置。 |
| 专用消费者监控工具 | Burrow | LinkedIn开源，专注于监控消费者组的消费进度和滞后量(Lag)，并提供评估和告警。 | 解决传统工具仅靠Lag数值判断消费健康度不准确的问题，对消费者敏感的场景很重要。 |
选择哪种工具组合，通常取决于以下几个关键因素：
- 团队规模与集群复杂度：对于初创团队或中小集群，从Kafka Manager或Kafka-UI开始是常见选择。当集群规模扩大、指标需求变复杂时，Prometheus + Grafana 几乎是必经之路。
- 核心监控需求：如果对消费者消费状态的健康度判断有严格要求（例如金融、交易场景），Burrow 这样的专门工具不可或缺。
- 预算与运维能力：商业版的Confluent Control Center提供一站式服务，但价格昂贵。开源方案功能强大，但需要投入开发和运维成本进行搭建和维护。
- 现有技术栈：如果公司已有成熟的Prometheus监控体系，那么集成Kafka JMX Exporter或Kafka Exporter来采集指标是最自然的扩展。
25 kafka常用命令
kafka4.0以前版本
kafka4.0
26 kafka使用场景
kafka的使用场景举例_kafka一般用来做什么 中的二、消息队列应用场景
消息队列MQ——三大核心作用 | 两大核心模型
