Kafka 为什么有 Topic 还要用 Partition？

面试考察点

1. 架构理解：面试官不仅仅是想知道你知不知道 Partition 的存在，更是想知道你有没有想明白 Kafka 作为分布式消息队列的核心设计，说白了，它靠什么把一台机器扛不住的流量摊到一群机器上。

2. 原理深度：Topic 和 Partition 谁是逻辑概念、谁是物理实体，消息怎么路由到分区，分区和消费者怎么对应，这条链路能不能一口气讲清楚。

3. 实践意识：分区数怎么定？分区多了好还是少了好？分区带来的一致性代价（分区间无序）你踩过没有。这些只有真用过的人才有体感。

核心答案

先说结论：Topic 是逻辑上的消息分类，Partition 是物理上的水平分片。只有 Topic 没有 Partition 的话，Kafka 就退化成一个单机队列，撑不起分布式场景。

Partition 存在的意义就三条：

一句话记住：Topic 负责 “消息是什么”，Partition 负责 “消息放哪、谁来并行处理”。

深度解析

一、先看清 Topic 和 Partition 到底是什么关系

Topic 是一个逻辑概念，你创建一个 order-topic，它并不是一个实实在在的存储单元。真正落盘的是 Partition。每个 Partition 在 Broker 上对应一个独立的日志目录，里面是一段一段的 segment 文件。

上面这张图信息量不小，拆开说：

• Topic 只是挂名：生产者发消息时认的是 Topic，但 Kafka 内部会把这个 Topic 的消息按规则分发到具体 Partition。消费者订阅 Topic，实际消费的也是 Topic 背后的各个 Partition。
• Partition 才是物理实体：每个 Partition 对应 Broker 上一块实打实的日志目录（比如 order-topic-0），消息以 append 的方式追加到 segment 文件末尾，这就是 Kafka 顺序写磁盘、吞吐高的根基。
• 分区散在多台机器：三个分区的 Leader 分别落在三台 Broker 上，写入压力天然被摊成三份。想再快？加分区、加机器就行，这就是水平扩展。
• 副本跟着分区走：每个 Partition 可以配置多个副本，一个 Leader 对外提供读写，其余 Follower 拉取同步。Leader 所在机器挂了，从 Follower 里选一个顶上来，分区级别的高可用就出来了。

二、并行为王：Partition 是 Kafka 吞吐的发动机

假设一个 Topic 只有 1 个分区，那么不管你集群有 50 台机器，这个 Topic 的读写永远只落在一台 Broker 上，因为一个分区在同一时刻只能有一个 Leader 负责读写。机器再多也是围观群众。

分区一多，画风就变了：

• 生产端：多条消息可以被并发地写进不同分区，互不干扰。分区数越多，可并行的写入通道越多。
• 消费端：消费者组里，一个分区同一时刻只会分配给组内一个消费者。4 个分区最多让 4 个消费者真正并行干活。分区数直接决定了消费并行度的上限。

这里有个经典误区顺带说一下：消费者组里塞 8 个消费者去消费 4 个分区，多出来的 4 个全程摸鱼，因为一个分区不能被组内两个消费者同时消费，不然同一条消息被消费两次，offset 就乱套了。

三、消息怎么进分区？key 说了算

生产者发消息时，分区路由规则很简单：

• 指定了分区号：直接进那个分区，想进哪个进哪个。
• 消息带 key：对 key 做 murmur2 哈希，再对分区数取模，partition = murmur2(keyBytes) % numPartitions。同一个 key 的消息永远落同一个分区，“同一个订单的消息保序” 靠的就是这一招。
• 没 key：Kafka 2.4 之前用轮询（round-robin），2.4 之后默认换成粘性分区（Sticky Partitioner），先可着一批消息猛灌一个分区，攒够了再换下一个，目的是把批量发送的优势拉满。

// 同一个订单 ID 的消息,保证进同一个分区,分区内天然有序
ProducerRecord<String, String> record =
        new ProducerRecord<>("order-topic", orderId, orderMessage);
producer.send(record);

四、代价：分区不是越多越好

分区带来扩展性的同时，也带来了两个必须认账的代价：

1. 分区内有序，分区间无序。Kafka 只保证单个分区内的消息顺序。设置了 key 还好，同 key 进同分区；没设 key，全局顺序就别想了。需要全局有序的业务（比如强顺序的数据库 binlog 同步），只能委屈 Topic 用 1 个分区。
2. 分区数是消费并行度的天花板，而且分区越多，Leader 选举、Rebalance、副本同步的开销越大，Broker 端打开的文件句柄也越多。生产上分区数别拍脑袋，按目标吞吐除以单分区吞吐来估算，一般单分区常规配置能扛每秒几万到十几万条消息（视消息大小和配置而定），留出余量再向上取整。

面试高频追问

1. 追问一：分区数设置多少合适？

   • 按吞吐目标反推：目标 TPS ÷ 单分区 TPS，再考虑消费者的处理能力、Broker 数量，留 20%-50% 余量。宁少勿多，分区加下去容易，减下来要命。

2. 追问二：怎么保证某个业务的消息全局有序？

   • 单分区 Topic（牺牲吞吐），或者消息带 key 让同一业务实体的消息落同一分区（局部有序）。

3. 追问三：消费者数量超过分区数会怎样？

   • 多余消费者闲置。想让消费者真并行，分区数 ≥ 消费者数。

4. 追问四：Leader Partition 挂了怎么办？

   • Controller 从该分区的 ISR（与 Leader 保持同步的副本列表）里选一个 Follower 提升为新 Leader，ISR 为空时就要看 unclean.leader.election.enable 配置了，开了可能丢消息，不开就等旧 Leader 回来，可用性和一致性的经典取舍。

5. 追问五：Rebalance 了解吗？什么时候触发？

   • 消费者组内成员增减、订阅的 Topic 分区数变化、消费者被踢出（心跳超时）都会触发。Rebalance 期间消费者全体暂停消费（新一代增量协同协议能缓解），这也是分区数不能乱设的原因之一。

常见面试变体

• “Kafka 的消息模型是什么样的？Topic、Partition、Replica、Segment 什么关系？”
• “为什么 Kafka 吞吐量这么高？”（顺序写 + 零拷贝 + 分区并行，这条题的答案可以复用）
• “Kafka 怎么保证消息顺序性？”
• “增加分区数有什么影响？”（旧 key 的哈希映射会变，同 key 消息可能进新分区，破坏局部有序）

记忆口诀

Topic 管归类，Partition 管干活；分区散多机，并行提吞吐；区内保有序，区间不保证；分区定上限，消费者不越界。

总结

Topic 解决 “消息怎么分类” 的逻辑问题，Partition 解决 “消息怎么分布、怎么并行” 的物理问题。水平扩展、并行读写、负载均衡加高可用，全靠 Partition 这个最小分配单元撑着。把分区和顺序性、消费者并行度的关系也讲出来，这道题就不是及格，是加分。