如何介绍 Kafka 的基本机制？

核心回答

Kafka 可以理解为分布式、可持久化、可重放的事件日志系统，常用于服务间异步解耦、日志采集和流式数据管道。介绍基本机制时，可以沿着“生产消息 → 分区存储与复制 → 消费并提交进度”这条线说。

1. 生产：Producer 把消息发送到 Topic。一个 Topic 可以拆成多个 Partition，生产者根据指定分区、消息键或分区策略选择目标分区，向该分区的 Leader 写入。
2. 存储：Partition 是追加式日志，消息在分区内有递增的 offset。分区可以分布在不同 Broker 上，并配置副本，由 Follower 拉取 Leader 的日志。分区提供并行能力，副本提供故障恢复能力，两者作用不同。
3. 消费：Consumer 主动拉取消息。以 Kafka 4.1 的普通 Consumer Group 为例，同组成员分担分区，一个分区在组内同一时刻分配给一个消费者；不同组可以独立读取同一份日志，并维护各自进度。
4. 恢复与清理：消费者提交 offset，供重启或分区重新分配后恢复。消息不会因为被某个组消费就立即删除，而是按 Topic 的保留、压缩等策略清理，因此在数据仍保留时可以重放。

进一步解释

offset、消费位置和提交位置是什么关系？

offset 标识的是某个分区内的位置，不是整个 Topic 的全局序号，也不是全局消息 ID。压缩、事务等场景下，消费者看到的 offset 不一定连续。

当前拉取位置会随拉取推进，已提交位置用于故障恢复。提交的含义是“下一步从哪里继续”，并不自动证明此前的业务操作都成功。

例如某分区的 40～49 号记录都已处理，下一条待处理记录是 50，可以提交位置 50。若业务处理完却在提交前崩溃，恢复后可能重复处理；若先提交再处理，崩溃后可能跳过未完成的业务。因此常见做法是处理成功后提交，并让业务写入具有幂等性。异步并行处理时，还要避免越过尚未完成的记录提交进度。

消息可靠性靠什么？

生产者要检查发送结果，合理处理重试；Broker 侧依赖副本、同步状态及选主机制。acks=all 要求同步副本集合确认，还应结合副本数、min.insync.replicas 和故障场景理解，不能解释为“集群所有机器都确认”或“任何故障都不会丢”。副本确认也不是每条消息都立即完成物理刷盘的承诺。

幂等生产者主要处理发送重试造成的重复写入。Kafka 事务能在适用范围内，把输出消息和消费进度作为一个原子单元；它不会自动把外部数据库更新、扣款等操作一并纳入事务。业务是否重复执行，仍需按实际处理链路设计。

为什么有较好的吞吐能力？

主要来自分区并行、批量发送与压缩、日志追加写入，以及对操作系统页缓存和高效数据传输的利用。批量可以减少请求和 I/O 开销，但等待凑批也可能增加延迟；冷数据读取、网络、磁盘和消费端处理都可能成为瓶颈，不能只用一个固定吞吐数字概括。

常见追问

用用户 ID 作分区键，有什么优缺点？

在分区数和分区规则不变时，同一用户的消息通常落到同一分区，便于按用户维护状态和顺序处理。但大用户可能形成热点，让一个分区积压而其他分区空闲；同组增加消费者也不能把这个分区同时分给多个成员来解决问题。

应先确认业务真正要求的是按用户、按订单，还是其他粒度有序。拆分热点键能提高并行度，但会改变原来的顺序边界；增加分区也可能改变键到分区的映射，需要考虑迁移期间的顺序。即使记录在分区内有序，生产端重试配置或消费端并行执行也可能让业务完成顺序发生变化。

Kafka 是否必须依赖 ZooKeeper？

旧版本曾使用 ZooKeeper 管理集群元数据；Kafka 4.0 起移除了 ZooKeeper 模式，使用 KRaft。这里的元数据协调机制与业务分区日志的 Leader/Follower 复制，需要分开理解。

参考资料