Kafka分区数怎么定？从踩坑到实战的完整指南

1. 从一个真实踩坑说起：分区数拍脑袋定的代价

刚接触消息队列那会儿，我对 Kafka Partition 的认知基本停留在“多分几个吞吐就高”这个层面。有一次做一个订单异步处理的项目，上游每秒峰值大概两万条消息，我心想这还不简单，直接给 Topic 开了 64 个分区，觉得肯定稳了。结果上线第三天就出事了——消费端有将近一半的消费者实例处于空转状态，而另外几个实例的 CPU 却跑满了，消息积压量在监控面板上画出一条陡峭的上升曲线。

排查了大半天才搞明白：消费者组里的实例数只有 8 个，而分区有 64 个，Kafka 的分配策略是每个分区只能被同一个消费者组内的一个消费者消费，所以 64 个分区被分给了 8 个消费者，每个消费者分到 8 个分区。问题在于，我的消息 key 设计有问题，导致数据严重倾斜，某几个分区里的消息量是其他分区的十几倍，拿到这些“热点分区”的消费者自然就被压垮了。

这次教训让我意识到，Kafka Partition 远不是“设个数字”那么简单。它牵扯到吞吐量、顺序性、消费者并行度、数据倾斜、再平衡等一连串问题。这篇文章就把我在实际项目里对 Kafka Partition 的理解和踩过的坑，系统地聊一聊。不管你是刚接触 Kafka 的新手，还是已经用了一段时间但总觉得“哪里不太对”的开发者，应该都能从中找到一些有用的东西。

2. Partition 到底是什么：从存储结构说起

2.1 分区是 Kafka 并行处理的最小单元

要理解 Partition，得先理解 Kafka 的 Topic 结构。一个 Topic 在逻辑上是一个消息的类别或者频道，但在物理层面，Topic 被切分成了若干个 Partition。每个 Partition 在 Broker 上对应一个目录，目录里面是一段一段的日志文件（Log Segment）。消息被追加写入这些日志文件，每条消息在 Partition 内有一个唯一的偏移量，也就是 Offset。

这个设计的关键在于：Partition 是 Kafka 实现水平扩展和并行处理的基本单位。一个 Topic 有多个 Partition，这些 Partition 可以分散在不同的 Broker 上，这样单个 Topic 的存储容量和读写吞吐就不再受限于单台机器。生产者可以同时往多个 Partition 写，消费者也可以同时从多个 Partition 读，并行度直接跟 Partition 数量挂钩。

打个比方，Topic 就像一个大仓库，Partition 就是仓库里的几条独立传送带。货物从不同的传送带进来，也从不同的传送带出去，每条传送带互不干扰。传送带越多，理论上同时能处理的货物就越多，但传送带本身也需要占用空间和维护成本。

2.2 分区内的有序性：一把双刃剑

Kafka 只保证Partition 内消息有序，不保证 Topic 级别的全局有序。这个特性非常关键，它既是 Kafka 高性能的基石，也是很多业务问题的根源。

为什么只保证分区内有序？因为如果要保证全局有序，那就意味着所有消息必须走同一个 Partition，那并行度就退化成 1 了，跟单机队列没区别。Kafka 选择把有序性的粒度交给用户来控制——你如果需要某些消息严格有序，就把它们放到同一个 Partition 里；如果不需要，就让它分散到多个 Partition 去并行处理。

实际项目中，这个特性最常见的用法就是：用业务主键作为消息 key。比如订单 ID、用户 ID、设备 ID，Kafka 默认的分区器会对 key 做哈希，同一个 key 的消息永远落到同一个 Partition。这样就能保证同一个订单的所有状态变更消息是有序的，而不同订单之间则可以并行处理。

注意：如果你的消息没有指定 key，Kafka 默认使用轮询（Round-Robin）或者粘性分区（Sticky Partitioning，2.4 版本之后）策略，消息会均匀分散到各个 Partition，此时不保证任何顺序。

2.3 分区与副本：高可用的基础

每个 Partition 可以有多个副本（Replica），其中一个是 Leader，其余是 Follower。生产者和消费者只跟 Leader 交互，Follower 负责从 Leader 同步数据。当 Leader 所在的 Broker 挂掉时，会从 Follower 中选出一个新的 Leader，保证服务不中断。

副本机制跟 Partition 的关系是：Partition 是数据分片的概念，副本是数据冗余的概念。一个 Partition 的多个副本不会放在同一个 Broker 上（否则 Broker 挂了副本也没了），而是分散在不同的 Broker。所以如果你的集群有 3 个 Broker，副本因子设为 3，那每个 Partition 的三个副本就分别落在三台机器上。

这里有个容易混淆的点：分区数增加，并不意味着副本数增加。分区数决定并行度，副本数决定容错能力，两者是正交的。你可以有 100 个分区但每个分区只有 1 个副本（不推荐，没有容错），也可以有 3 个分区但每个分区有 5 个副本（副本数不能超过 Broker 数量）。

3. 分区数的选择：没有银弹，但有方法论

3.1 分区数决定了消费者并行度的上限

这是分区数最直接的影响。在一个消费者组内，同时活跃的消费者实例数不能超过分区数。如果你有 8 个分区，消费者组里最多只有 8 个实例能同时消费；第 9 个实例加入后，它会处于空闲状态，分不到任何分区。

所以分区数的第一个约束来自你的消费端：你期望的最大消费并行度是多少？如果你预计未来消费者实例最多会扩展到 16 个，那分区数至少要是 16。反过来，如果你只有 3 个消费者实例，却开了 30 个分区，那就有 27 个分区的消费能力被浪费了（除非你后续会扩容消费者）。

但这里有个常见的误区：很多人觉得“分区数等于消费者数”就是最优的。实际上不一定。如果每个消费者的处理能力很强，而分区数刚好等于消费者数，那每个消费者负责一个分区，一旦某个消费者处理慢，它负责的分区就会积压，而其他消费者帮不上忙。适当多留一些分区（比如消费者数的 1.5 到 2 倍），可以让 Kafka 的再平衡机制在某个消费者挂掉时，把它负责的分区分配给其他消费者，提高弹性。

3.2 吞吐量估算：从生产端和消费端两头算

分区数的第二个约束来自吞吐量。这里要分生产端和消费端分别估算。

生产端：单个 Partition 的写入吞吐是有限的，取决于 Broker 的磁盘顺序写能力、网络带宽、批量大小等。经验值上，单个 Partition 在生产端可以支撑每秒几万到十几万条消息（取决于消息大小和配置）。如果你需要每秒写入 100 万条消息，那至少需要 10 到 20 个分区。

消费端：单个 Partition 的消费吞吐取决于消费者的处理逻辑。如果消费者只是简单地把消息转发到另一个地方，那单分区每秒处理几万条没问题；但如果消费者每条消息都要做复杂的数据库操作或者远程调用，那单分区每秒可能只能处理几百条。这时候分区数就要根据消费能力来倒推。

一个实用的估算公式是：

所需分区数 = max(目标生产吞吐 / 单分区生产吞吐, 目标消费吞吐 / 单分区消费吞吐)

比如目标生产吞吐是 50 万条/秒，单分区生产吞吐是 5 万条/秒，那生产端需要 10 个分区。目标消费吞吐也是 50 万条/秒，但单分区消费吞吐只有 1 万条/秒（因为消费逻辑复杂），那消费端需要 50 个分区。最终分区数应该取 50，因为瓶颈在消费端。

3.3 分区数不是越多越好：那些容易被忽略的成本

很多人觉得分区数开大一点总没坏处，大不了用不上。但实际上，分区数过多会带来一系列问题：

文件句柄和内存开销：每个 Partition 在 Broker 上都对应一组文件（日志文件、索引文件等），分区数越多，Broker 需要打开的文件句柄就越多。同时，每个 Partition 的 Leader 和 Follower 都需要占用一定的内存来维护元数据和缓存。如果分区数过多，Broker 的内存压力会显著增加。

再平衡时间变长：当消费者组发生再平衡（比如有消费者加入或离开）时，Kafka 需要重新分配分区。分区数越多，再平衡的过程就越慢，期间整个消费者组会暂停消费。在极端情况下，再平衡可能持续几十秒甚至几分钟，对实时性要求高的业务是不可接受的。

端到端延迟增加：Kafka 的生产者端有 linger.ms 配置，消费者端有 fetch.min.bytes 等配置，分区数多了之后，每个分区积累到足够批量数据的时间可能变长，导致端到端延迟增加。

故障恢复变慢：当 Broker 挂掉时，它上面的所有 Partition Leader 都需要重新选举。分区数越多，选举和恢复的过程就越长。

所以分区数的选择是一个权衡：太少会限制并行度和吞吐，太多会增加运维复杂度和延迟。我的经验是，对于大多数业务场景，分区数在 10 到 100 之间是比较合理的区间。超过 100 个分区就要仔细评估是否真的需要，超过 1000 个分区基本上就是设计有问题了。

3.4 一个实际项目的分区数计算过程

拿我之前做过的一个日志采集项目举例。需求是这样的：每天采集大约 10 亿条日志，峰值集中在晚上 8 点到 10 点，峰值 QPS 大约是 5 万条/秒。日志消息平均大小 1KB。消费端需要把日志写入对象存储，单条日志的处理时间大约是 0.1 毫秒。

先算生产端：5 万条/秒，每条 1KB，总带宽是 50MB/s。单个 Partition 在千兆网卡下大概能支撑 10MB/s 到 20MB/s 的写入，所以生产端需要 3 到 5 个分区。

再算消费端：单条处理 0.1 毫秒，那单个消费者线程每秒能处理 10000 条。如果每个消费者实例开 4 个线程，那单个实例每秒能处理 40000 条。5 万条/秒需要 1.25 个实例，向上取整是 2 个实例。但考虑到消费者实例可能挂掉需要容错，以及未来业务增长，我最终定了 12 个分区，消费者实例部署 4 个，每个实例 3 个线程。

这个配置跑了一年多，峰值时消费延迟稳定在 200 毫秒以内，没有出现过积压。后来业务量翻倍，我把分区数扩到了 24 个，消费者实例扩到 8 个，同样很平稳。

4. 分区扩容与数据倾斜：那些绕不过去的坑

4.1 分区只能加不能减：扩容的正确姿势

Kafka 的分区数只能增加，不能减少。这个限制来自 Kafka 的设计：分区减少意味着要合并数据，而合并过程中 Offset 会变得混乱，消费者无法正确地继续消费。所以如果你一开始分区数设少了，只能通过增加分区来解决。

增加分区的命令很简单：

kafka-topics.sh --bootstrap-server broker1:9092 \ --alter --topic my-topic --partitions 24

但这里有几个关键问题需要注意：

第一，分区增加后，消息的 key 到分区的映射会发生变化。因为 Kafka 默认的分区器是hash(key) % 分区数，分区数从 12 变成 24 后，原来落在分区 3 的 key 现在可能落到分区 15。这意味着同一个 key 的历史消息和新消息可能在不同的分区里，如果你依赖分区内有序性来处理业务逻辑，就会出问题。

第二，增加分区不会自动重新分配已有数据。已有的消息还在原来的分区里，只有新写入的消息才会按照新的分区数来分配。所以增加分区后，各个分区的数据量可能不均匀，需要一段时间才能重新平衡。

第三，增加分区会触发消费者组的再平衡。所有消费者都会暂停消费，等待分区重新分配。如果分区数很多，这个过程可能持续几秒到几十秒。

实操心得：如果业务对消息顺序有严格要求，增加分区前一定要评估影响。一个常见的做法是，在增加分区的同时，把消费者端的处理逻辑改成幂等的，这样即使消息顺序变了，也不会导致数据错误。

4.2 数据倾斜：分区数够但负载不均的元凶

数据倾斜是分区使用中最隐蔽的问题之一。表面上看分区数够多，但实际运行时某些分区特别忙，某些分区几乎没数据。造成数据倾斜的原因主要有两个：

一是 key 的分布不均匀。比如你用用户 ID 做 key，但你的业务里有一个超级大客户，它的用户 ID 产生的消息占了总量的 30%。那这个 key 对应的分区就会成为热点，其他分区都很闲。

二是分区器选择不当。Kafka 默认的分区器是哈希取模，对于分布均匀的 key 效果很好，但对于有热点 key 的场景就不行了。有些团队会自定义分区器，比如把热点 key 单独映射到一个分区，或者用一致性哈希来减少扩容时的数据迁移。

解决数据倾斜的思路有几种：

• 加盐（Salting）：在 key 后面拼接一个随机后缀，把热点 key 打散到多个分区。但这样会破坏同一个 key 的有序性，需要业务端做额外的聚合处理。
• 自定义分区器：根据业务特点设计分区策略，比如把大客户的 key 单独处理，或者用范围分区代替哈希分区。
• 拆分 Topic：把热点业务单独拆到一个 Topic，用独立的分区资源来处理。

4.3 分区分配策略：Range、RoundRobin 和 Sticky

消费者组内的分区分配策略直接影响负载均衡效果。Kafka 提供了三种内置策略：

Range 策略的问题在于，如果分区数不能被消费者数整除，前面的消费者会多分到一个分区。比如 7 个分区、3 个消费者，分配结果是 3、2、2。如果消费者数量经常变化，这种倾斜会更明显。

Sticky 策略是目前最推荐的，它在再平衡时尽量保留原有的分配关系，只移动必要的分区，大大减少了再平衡的开销。在 Kafka 2.4 之后，Sticky 已经是默认策略了。

5. 分区与副本的协同：高可用背后的机制

5.1 Leader 选举与 ISR 机制

每个 Partition 都有一个 Leader 和若干个 Follower。Leader 负责处理所有的读写请求，Follower 负责从 Leader 同步数据。Kafka 维护一个 ISR（In-Sync Replicas）列表，里面是跟 Leader 保持同步的副本。只有 ISR 里的副本才有资格被选为新的 Leader。

当 Leader 挂掉时，Kafka 会从 ISR 里选出一个新的 Leader。这个选举过程通常很快，几秒内就能完成。但如果 ISR 里的副本都挂了，那就只能从非 ISR 副本里选，这时候可能会丢失数据（因为非 ISR 副本可能落后于原来的 Leader）。

这里涉及一个关键配置：min.insync.replicas。它规定了至少要有多少个副本在 ISR 里，生产者才能成功写入。如果 ISR 里的副本数少于这个值，生产者会收到异常。这个配置配合生产者的acks=all使用，可以保证消息不丢失。

举个例子：副本因子是 3，min.insync.replicas设为 2。那生产者写入时，至少要有 2 个副本确认收到消息才算成功。如果挂了一个 Broker，ISR 里还剩 2 个副本，仍然满足条件，写入继续。如果再挂一个，ISR 里只剩 1 个副本，不满足min.insync.replicas=2，生产者就会报错，避免数据丢失。

5.2 副本因子怎么定：可用性与成本的平衡

副本因子决定了每个 Partition 有多少份数据拷贝。副本因子越高，容错能力越强，但存储成本和网络开销也越大。

• 副本因子 1：没有容错能力，Broker 挂了数据就丢了。只适合测试环境或者可以容忍数据丢失的场景。
• 副本因子 2：可以容忍 1 个 Broker 挂掉。存储成本是 2 倍。适合对成本敏感但又需要一定容错的场景。
• 副本因子 3：可以容忍 2 个 Broker 挂掉。存储成本是 3 倍。这是生产环境最常用的配置，也是 Kafka 官方推荐的。

副本因子不能超过 Broker 数量。如果你只有 2 个 Broker，副本因子最多只能是 2。所以如果你的集群只有 2 台机器，却想要副本因子 3，那是不可能的。这种情况下要么加机器，要么接受副本因子 2。

5.3 分区重分配：Broker 扩容后的数据迁移

当你给集群增加新的 Broker 时，Kafka 不会自动把已有的分区迁移到新 Broker 上。你需要手动触发分区重分配。Kafka 提供了一个工具kafka-reassign-partitions.sh来做这件事。

操作流程大致是：

1. 生成重分配计划：指定哪些 Topic 需要重分配，以及目标 Broker 列表。
2. 执行重分配：Kafka 会把分区数据从旧 Broker 复制到新 Broker。
3. 验证重分配结果：确认所有分区都达到了预期的副本分布。

这个过程会占用大量的网络带宽和磁盘 IO，建议在业务低峰期进行。同时，重分配过程中会触发 Leader 切换，可能对生产者和消费者造成短暂的影响。

注意事项：分区重分配时，要确保目标 Broker 有足够的磁盘空间。如果新 Broker 的磁盘空间不足，重分配会失败，而且可能导致数据不一致。

6. 分区相关的常见问题与排查技巧

6.1 消费积压：从分区维度定位瓶颈

消费积压是最常见的问题之一。排查时，首先要看的是每个分区的积压情况，而不是总的积压量。因为总积压量可能是由某几个热点分区造成的，其他分区其实很健康。

可以用 Kafka 自带的命令查看每个分区的消费偏移量：

kafka-consumer-groups.sh --bootstrap-server broker1:9092 \ --describe --group my-consumer-group

输出里会显示每个分区的 CURRENT-OFFSET、LOG-END-OFFSET 和 LAG。如果某个分区的 LAG 特别大，而其他分区很小，那就是数据倾斜问题。如果所有分区的 LAG 都很大，那就是消费能力不足，需要增加消费者实例或者优化消费逻辑。

6.2 再平衡风暴：原因与应对

再平衡风暴是指消费者组频繁发生再平衡，导致消费几乎无法正常进行。常见原因有：

• 消费者实例频繁上下线：比如容器化部署时，健康检查失败导致容器被反复重启。
• 消费者处理时间过长：超过了max.poll.interval.ms配置，Kafka 认为消费者已经死了，触发再平衡。
• 网络抖动：消费者与 Broker 之间的网络不稳定，导致心跳超时。

应对再平衡风暴的方法：

• 调整max.poll.interval.ms和session.timeout.ms，给消费者更长的处理时间。
• 优化消费逻辑，减少单次 poll 的处理时间。
• 使用静态成员资格（Static Membership），给每个消费者实例一个固定的 ID，这样短暂下线不会触发再平衡。

6.3 分区 Leader 不均：Broker 负载失衡的隐形推手

Kafka 在创建 Topic 时会尽量把 Leader 均匀分配到各个 Broker 上，但在运行过程中，如果某个 Broker 重启或者挂掉，Leader 可能会集中到少数 Broker 上。这会导致这些 Broker 的负载过高，而其他 Broker 很闲。

可以用以下命令查看 Leader 分布：

kafka-topics.sh --bootstrap-server broker1:9092 \ --describe --topic my-topic

如果发现 Leader 分布不均，可以用kafka-preferred-replica-election.sh工具触发优先副本选举，把 Leader 恢复到最初的分布。

6.4 常见问题速查表

7. 一些实战中的经验与建议

分区数的规划要留有余地。我一般会按照当前业务量的 2 到 3 倍来估算分区数，这样未来一两年内业务增长不需要频繁扩容。但也不能留太多，否则浪费资源。

消息 key 的设计要慎重。如果业务需要有序性，key 必须能唯一标识一个业务实体。如果不需要有序性，可以考虑不加 key，让 Kafka 用粘性分区策略均匀分配。

监控要覆盖分区维度。不要只看 Topic 级别的指标，要深入到每个分区的生产速率、消费速率、LAG、Leader 分布等。很多问题在 Topic 级别看不出来，但在分区级别一目了然。

扩容分区前一定要评估对顺序性的影响。如果业务依赖分区内有序，扩容后可能需要做数据迁移或者业务端的兼容处理。

副本因子和 min.insync.replicas 要配合使用。只设副本因子不设 min.insync.replicas，在极端情况下仍然可能丢数据。两者配合才能提供真正的持久性保证。

最后再分享一个小技巧：如果你不确定分区数设多少合适，可以先设一个保守的值（比如 12 或 24），然后通过压测来验证。压测时重点关注生产端的吞吐和延迟、消费端的 LAG 变化、Broker 的 CPU 和磁盘 IO。根据压测结果再调整分区数，比拍脑袋靠谱得多。