歡迎支援《RabbitMQ實戰指南》以及關注微信公眾號：朱小廝的部落格。

當一個主題被建立之後，依然允許我們對其做一定的修改，比如修改分割槽個數、修改配置等，這個修改的功能就是由kafka-topics.sh指令碼中的alter指令所提供。
我們首先來看如何增加主題的分割槽數。以前面的主題topic-config為例，當前分割槽數為1，修改為3，示例如下：

[[email protected] kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3
WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected
Adding partitions succeeded!
 
[
 
[email protected] kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --describe --topic topic-config
Topic:topic-config    PartitionCount:3  ReplicationFactor:1   Configs:
Topic: topic-config    Partition: 0 Leader: 2    Replicas: 2  Isr: 2
Topic: topic-config    Partition: 1 Leader: 0    Replicas: 0  Isr: 0
Topic: topic-config    Partition: 2 Leader: 1    Replicas: 1  Isr: 1
 

注意上面提示的告警資訊：當主題中的訊息包含有key時（即key不為null），根據key來計算分割槽的行為就會有所影響。當topic-config的分割槽數為1時，不管訊息的key為何值，訊息都會發往這一個分割槽中；當分割槽數增加到3時，那麼就會根據訊息的key來計算分割槽號，原本發往分割槽0的訊息現在有可能會發往分割槽1或者分割槽2中。如此還會影響既定訊息的順序，所以在增加分割槽數時一定要三思而後行。對於基於key計算的主題而言，建議在一開始就設定好分割槽數量，避免以後對其進行調整。

目前Kafka只支援增加分割槽數而不支援減少分割槽數。比如我們再將主題topic-config的分割槽數修改為1，就會報出InvalidPartitionException的異常，示例如下：

[[email protected] kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 1
WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected
Error while executing topic command : The number of partitions for a topic can only be increased. Topic topic-config currently has 3 partitions, 1 would not be an increase.
[2018-09-10 19:28:40,031] ERROR org.apache.kafka.common.errors.InvalidPartitionsException: The number of partitions for a topic can only be increased. Topic topic-config currently has 3 partitions, 1 would not be an increase.
 (kafka.admin.TopicCommand$)

為什麼不支援減少分割槽？
按照Kafka現有的程式碼邏輯而言，此功能完全可以實現，不過也會使得程式碼的複雜度急劇增大。實現此功能需要考慮的因素很多，比如刪除掉的分割槽中的訊息該作何處理？如果隨著分割槽一起消失則訊息的可靠性得不到保障；如果需要保留則又需要考慮如何保留。直接儲存到現有分割槽的尾部，訊息的時間戳就不會遞增，如此對於Spark、Flink這類需要訊息時間戳（事件時間）的元件將會受到影響；如果分散插入到現有的分割槽中，那麼在訊息量很大的時候，內部的資料複製會佔用很大的資源，而且在複製期間，此主題的可用性又如何得到保障？與此同時，順序性問題、事務性問題、以及分割槽和副本的狀態機切換問題都是不得不面對的。反觀這個功能的收益點卻是很低，如果真的需要實現此類的功能，完全可以重新建立一個分割槽數較小的主題，然後將現有主題中的訊息按照既定的邏輯複製過去即可。

雖然分割槽數不可以減少，但是分割槽對應的副本數是可以減少的，這個其實很好理解，你關閉一個副本時就相當於副本數減少了。不過正規的做法是使用kafka-reassign-partition.sh指令碼來實現，具體用法可以自行搜尋。

歡迎支援《RabbitMQ實戰指南》以及關注微信公眾號：朱小廝的部落格。