面试记录 2026-09-22
题目：Kafka 为什么有 Topic 还要用 Partition?
难度：medium
标签：db/mq/kafka, mq/kafka, general/knowledge, difficulty/medium
评分：⭐⭐⭐☆☆（3/5）
我的回答
为什么要设计一个分区呢？其实就是横向扩展的能力，因为 Kafka 的消息在 Topic 上其实是属于不同分区的，它其实是为了解决单机性能瓶颈问题，因为消息在单机上面存储的话，在消息过多，或者读写传输都会变得困难。因为单机磁盘读写都会有瓶颈，单机消息越多，其实读写都会比较困难，所以说引入了分区，其实就是为了提升横向扩展能力和性能的提升。
点评
优点：
- 抓到核心思路之一：分区是为了横向扩展、解决单机瓶颈——这是最主流的正面回答
- 提到"磁盘读写瓶颈"，触及了 Kafka 磁盘顺序 I/O 的关键
不足：
- 完全没提到"并行消费"——这是分区最本质的理由：一个 Partition 只能被一个消费者消费，分区数决定了消费者组的最大并行度
- 没提到"Partition 内有序"——分区提供了"分区级顺序"这个重要的语义保证
- 没提到容错：不同 Partition 可以分布在不同 Broker 上，某个 Broker 挂掉只影响它的 Partition
- 遗漏"Partition 数量与消费者的关系"——分区数是消费者组的天花板
补充（分区真正的四大作用）：
- 并行度上限：一个 Consumer Group 内，一个 Partition 只能被一个消费者消费，分区数决定了消费者的最大并行度
- 顺序保证：Partition 内消息严格有序，但跨 Partition 无序
- 横向扩展：分区可分布在不同 Broker 上，水平扩展写入/存储/读取能力
- 容错隔离：不同分区有独立的副本，Broker 故障时只影响对应分区的 Leader
完整讲解
第一部分：知识重点剖析
核心考点定位：考察是否理解 Kafka 分区设计的动机——不只是一个概念，而是"如何用分区实现高吞吐 + 局部有序 + 横向扩展"的完整设计权衡。
知识点拆解：
- 单一 Partition 的瓶颈：
- 顺序写盘只能由一个线程完成，无法多线程写
- 消费者只能单线程消费一个 Partition（因为要保持 offset 顺序）
- 单 Partition 的容量、QPS、带宽都受单机限制
- 分区的核心作用：
- 并行度：N 个 Partition → 消费者组最多 N 个消费者同时工作
- 顺序性：每个 Partition 是一个独立有序日志，全局无序但局部有序
- 扩展性：分区可分布在不同 Broker，扩容加节点+加分区
- 容错：每个分区有副本，Leader 挂掉由 ISR 副本接管
- Partition 数量的权衡：
- 太少：并行度不足，消费者打不满
- 太多：Rebalance 频率上升、文件句柄爆炸、元数据管理开销
- 经验值：单 Partition 单消费者 QPS 达到瓶颈时再加；一般不超过 100
- Partition Key 的作用：
hash(key) % numPartitions 决定路由；同一 Key 一定落同一分区，保证同一业务实体的顺序
- 消费者组与分区的硬约束：
- 一个 Partition 最多被组内一个消费者消费
- 消费者数 > 分区数时，多出的消费者空转
Topic 是业务语义的容器，Partition 是物理上并行处理的单位。
第二部分：考察方向与延伸递进
考察方向：
- 深度：Partition 数量与
log.dirs 目录的关系（多盘布局）、num.partitions 只能增加不能减少、消息压缩如何按分区进行
- 广度：与 RocketMQ 的 Queue 概念对比、与 Elasticsearch 的 Shard 类比
- 应用：如何评估分区数、如何处理分区扩容导致的顺序性丢失、如何排查 Rebalance 与分区数的关系
延伸递进面试题：
- Kafka 分区只能增加不能减少，为什么？如果分区多了怎么办？
- 解答要点：减少分区会破坏 offset 到消息的映射，已 commit 的 offset 失效；过多分区通过新建 Topic 迁移解决
- 同一订单要保证顺序消费，分区数应该设多少？
- 解答要点：分区数不决定 Key 的路由，路由只由
hash(orderId) % numPartitions 决定，与分区总数无关；只需保证 Key 一致
- Topic 有 20 个分区，消费者组只有 5 个消费者，每个消费者会分到几个分区？
- 解答要点：平均 4 个（RangeAssignor 或 CooperativeStickyAssignor 具体分配依算法）
第三部分：面试者参考回答（300-600 字口语化）
面试官您好，Kafka 之所以在 Topic 之下再引入 Partition，核心是解决四个问题。
第一个是并行度。Kafka 的顺序写盘和消费者单分区消费都决定了单分区是有性能天花板的，加 Partition 就能让多个 Broker 并行写、多个消费者并行读，这是分区最本质的价值——决定了一个消费者组最大能有多少消费者同时工作。
第二个是顺序性。Kafka 保证的是"分区内有序"，同一 Partition 内消息 offset 严格递增。业务上通常用 Partition Key 来路由，比如 hash(orderId) % numPartitions，同一订单一定落同一分区，从而实现"同一业务实体的顺序消费"，全局则不保证有序。
第三个是横向扩展。Partition 可以分布在不同 Broker 上，扩容时加 Broker 加 Partition 就能线性扩展吞吐和存储。
第四个是容错隔离。每个 Partition 有自己的副本（ISR），某个 Broker 挂掉只会影响它上面的 Partition Leader，其他 Partition 继续服务，故障被隔离。
当然分区也不是越多越好：分区多了 Rebalance 频率上升，元数据管理开销大，文件句柄也容易爆。经验做法是按单分区单消费者的 QPS 上限反推，一般不超过 100。
面试记录 2026-10-12（第 2 次）
题目：Kafka 为什么有 Topic 还要用 Partition?
难度：medium
标签：db/mq/kafka, mq/kafka, difficulty/medium
评分：⭐⭐⭐⭐☆（4/5）
练习次数：2
我的回答
Topic 是主题，主要是相当于订阅业务方面的层面的信息。而 Partition 是分区，是为了承载更高并发量而做的类似于分布式逻辑的承载更多并发的物理机构。
二者定位的逻辑就是不一样的。Topic 是业务层面的，Partition 是物理层面的。Partition 解决的是并发量跟数据量的问题。
点评
优点：
- 抓住了核心定位差异——Topic 业务语义层 / Partition 物理承载层，这个抽象很清晰
- 明确点出 Partition 解决"并发量"和"数据量"两个维度，比 Q1 的抽象能力强
- 用"类似于分布式逻辑"来类比，说明有底层直觉
不足：
- 完全没提"顺序性"——这是 Partition 语义里最关键的一半："分区内有序、跨分区无序"，几乎所有业务用 Key 路由做局部顺序都建立在这个约束上
- 没提"消费者组与分区的硬约束"——一个 Partition 只能被组内一个消费者消费，这是"并行度上限"的来源
- 没提到容错隔离：分区分布在不同 Broker + ISR 副本，Broker 故障只影响对应分区
补充：
- 分区数的取舍：太少→并行度不足；太多→Rebalance 频繁、文件句柄爆、元数据管理开销大；经验值一般不超过 100
- Partition Key 的作用：
hash(key) % numPartitions，同一 Key 落同一分区，是"业务实体级顺序"的实现基础
ℹ️ 完整讲解见上方首次记录（2026-09-22）