Partition 数量能不能减少

验证：真实尝试把分区数从3改成2

命令 · shell $ kafka-topics.sh --describe --topic order-demo | head -1 Topic: order-demo PartitionCount: 3 ... $ kafka-topics.sh --alter --topic order-demo --partitions 2

真实实测 · 本机执行输出

Error while executing topic command :
The topic order-demo currently has 3 partition(s); 2 would not be an increase.

org.apache.kafka.common.errors.InvalidPartitionsException: The topic order-demo
currently has 3 partition(s); 2 would not be an increase.

错误信息本身说得很直白：这个操作被定义为"increase"(增加)，2小于当前的3，根本不满足这个操作的前提，直接被拒绝。

验证：反过来增加分区数，真实立刻成功

命令 · shell $ kafka-topics.sh --alter --topic order-demo --partitions 4

真实实测 · 本机执行输出

Topic: order-demo  PartitionCount: 4
  Partition 3  Leader: 1  Replicas: 1,2,3  Isr: 1,2,3   ← 真实新增的分区

增加分区真实是一件"无中生有"的操作——新分区3从一开始就是全新的、空的，不需要处理任何历史数据，Controller只需要真实决定它的副本放在哪几个broker上就行。而减少分区，真实要面对一个Kafka从设计上就没有解决的问题：如果真实要把分区2的数据合并回分区0或分区1，这些数据在物理上真实是完全独立的日志文件，合并意味着要重新排列消息的offset和物理存储顺序，而且如果分区2里还有消息使用不同的key（分区分配依赖key哈希），合并之后同一个key对应的消息真实可能被打散到不同分区，破坏"同一个key的消息在同一个分区"这个基本保证。真实想要"减少分区"，唯一的路是创建一个新的、分区数更少的topic，把数据真实重新生产一遍过去，再切换消费方，这是一个真实需要业务配合的迁移过程，不是一条命令能做到的。

分步演示：增加成功，减少被拒绝

每一步都是本文上面用kafka-topics.sh --alter跑出来的原始结果。

分区数真实只能往一个方向走

这一步新验证的操作

参考与说明

数据来自本机3节点Kafka 4.3.1集群，topic order-demo，真实分别尝试减少和增加分区数两个方向。
没有验证：真实通过"创建新topic+重新生产数据"完成分区数减少的完整迁移流程；分区数增加对已有key的分区路由(哈希取模基数变化)造成的真实影响，本系列《消息顺序》一文提到过key到分区的映射关系，增加分区会让同一个key真实可能落到新的分区上。

下一篇 · KAFKA 内部原理 65

Kafka 集群滚动升级怎么保证不丢消息