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、设备 IDKafka 默认的分区器会对 key 做哈希同一个 key 的消息永远落到同一个 Partition。这样就能保证同一个订单的所有状态变更消息是有序的而不同订单之间则可以并行处理。注意如果你的消息没有指定 keyKafka 默认使用轮询Round-Robin或者粘性分区Sticky Partitioning2.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按分区范围分配给消费者实现简单每个消费者分到的分区连续容易倾斜前面的消费者分到更多分区RoundRobin轮询分配分区分配均匀再平衡时分区迁移量大Sticky尽量保持原有分配同时均衡再平衡时迁移量小分配均匀实现复杂需要 Kafka 2.4Range 策略的问题在于如果分区数不能被消费者数整除前面的消费者会多分到一个分区。比如 7 个分区、3 个消费者分配结果是 3、2、2。如果消费者数量经常变化这种倾斜会更明显。Sticky 策略是目前最推荐的它在再平衡时尽量保留原有的分配关系只移动必要的分区大大减少了再平衡的开销。在 Kafka 2.4 之后Sticky 已经是默认策略了。5. 分区与副本的协同高可用背后的机制5.1 Leader 选举与 ISR 机制每个 Partition 都有一个 Leader 和若干个 Follower。Leader 负责处理所有的读写请求Follower 负责从 Leader 同步数据。Kafka 维护一个 ISRIn-Sync Replicas列表里面是跟 Leader 保持同步的副本。只有 ISR 里的副本才有资格被选为新的 Leader。当 Leader 挂掉时Kafka 会从 ISR 里选出一个新的 Leader。这个选举过程通常很快几秒内就能完成。但如果 ISR 里的副本都挂了那就只能从非 ISR 副本里选这时候可能会丢失数据因为非 ISR 副本可能落后于原来的 Leader。这里涉及一个关键配置min.insync.replicas。它规定了至少要有多少个副本在 ISR 里生产者才能成功写入。如果 ISR 里的副本数少于这个值生产者会收到异常。这个配置配合生产者的acksall使用可以保证消息不丢失。举个例子副本因子是 3min.insync.replicas设为 2。那生产者写入时至少要有 2 个副本确认收到消息才算成功。如果挂了一个 BrokerISR 里还剩 2 个副本仍然满足条件写入继续。如果再挂一个ISR 里只剩 1 个副本不满足min.insync.replicas2生产者就会报错避免数据丢失。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来做这件事。操作流程大致是生成重分配计划指定哪些 Topic 需要重分配以及目标 Broker 列表。执行重分配Kafka 会把分区数据从旧 Broker 复制到新 Broker。验证重分配结果确认所有分区都达到了预期的副本分布。这个过程会占用大量的网络带宽和磁盘 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 常见问题速查表问题现象可能原因排查方法解决方案消费积压集中在少数分区数据倾斜查看各分区 LAG加盐、自定义分区器、拆分 Topic所有分区都积压消费能力不足查看消费者 CPU 和线程数增加消费者实例、优化消费逻辑频繁再平衡消费者超时或频繁上下线查看消费者日志和心跳调整超时配置、使用静态成员Leader 分布不均Broker 重启或挂掉查看 Topic 描述触发优先副本选举生产者写入超时ISR 不足或 Broker 负载高查看 ISR 和 Broker 指标调整 min.insync.replicas、扩容分区数过多导致延迟高批量积累时间变长查看端到端延迟指标减少分区数或调整批量配置7. 一些实战中的经验与建议分区数的规划要留有余地。我一般会按照当前业务量的 2 到 3 倍来估算分区数这样未来一两年内业务增长不需要频繁扩容。但也不能留太多否则浪费资源。消息 key 的设计要慎重。如果业务需要有序性key 必须能唯一标识一个业务实体。如果不需要有序性可以考虑不加 key让 Kafka 用粘性分区策略均匀分配。监控要覆盖分区维度。不要只看 Topic 级别的指标要深入到每个分区的生产速率、消费速率、LAG、Leader 分布等。很多问题在 Topic 级别看不出来但在分区级别一目了然。扩容分区前一定要评估对顺序性的影响。如果业务依赖分区内有序扩容后可能需要做数据迁移或者业务端的兼容处理。副本因子和 min.insync.replicas 要配合使用。只设副本因子不设 min.insync.replicas在极端情况下仍然可能丢数据。两者配合才能提供真正的持久性保证。最后再分享一个小技巧如果你不确定分区数设多少合适可以先设一个保守的值比如 12 或 24然后通过压测来验证。压测时重点关注生产端的吞吐和延迟、消费端的 LAG 变化、Broker 的 CPU 和磁盘 IO。根据压测结果再调整分区数比拍脑袋靠谱得多。