kafka 常见命令以及增加topic的分区数

kafka-topics.sh --bootstrap-server ${kafkaAddress} --create --topic ${topicName} --partitions ${partipartions} --replication-factor ${replication}

kafka-topics.sh --bootstrap-server ${kafkaAddress} --topic ${topicName} --describe

kafka-topics.sh --bootstrap-server ${kafkaAddress} --delete--topic ${topicName} --partitions ${partitions} --replication-factor ${replication}

kafka-topics.sh --bootstrap-server ${kafkaAddress} --list

kafka-console-consumer.sh --bootstrap-server ${kafkaAddress} --topic ${topicName} --from-beginning

kafka-consumer-groups.sh --describe --bootstrap-server ${kafkaAddress} --group ${groupName}

a.修改partitions数量

kafka-topics.sh --bootstrap-server ${kafkaAddress} --topic ${topicName} --alter --partitions 4

b.创建increase-replication-factor.json in config,配置各分区replication-factor位置

c.更新replication-factor

kafka-reassign-partitions.sh --bootstrap-server ${kafkaAddress} --reassignment-json-file config/increase-replication-factor.json --execute

情况是这样的，在我们系统中有多个Consumer的客户端（客户端个数是不确定的，因为在系统工作过程中有的业务节点会脱离，有些业务节点会增加进来），Producer也有多个。但是Producer发送的消息种类只有一种，所以topic只创建了一个， 消息量很大，所以使用了多个Consumer来处理。现在想实现如下的订阅/推送效果，多个Producer进行消息的推送，例如消息X1、X2、X3、X4、X5.。。。。。。然后由多个Consumer分别进行拉去，Consumer1拉取到：X1、X4、X7。。。Consumer2拉取到：X2、X5、X8.。。。。。。。。如此类推

分区的原因

（1）方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；

（2）可以提高并发，因为可以以Partition为单位读写了

（1）  指明 partition 的情况下，直接将指明的值直接作为 partiton 值；

（2）没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；

（3） 既没有 partition 值又没有 key 值的情况下， kafka采用Sticky Partition(黏性分区器)，会 随机选择一个分区，并尽可能一直使用该分区，待该分区的batch已满或者已完成，kafka再随机一个分区进行使用.(以前是一条条的轮询，现在是一批次的轮询)

在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin，StickyAssignor。

Range是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。

C1-0 将消费 0, 1, 2, 3 分区

C2-0 将消费 4, 5, 6 分区

C2-1 将消费 7, 8, 9 分区

第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

我们再来看一下StickyAssignor策略，“sticky”这个单词可以翻译为“粘性的”，Kafka从0.11.x版本开始引入这种分配策略，它主要有两个目的：

分区的分配要尽可能的均匀，分配给消费者者的主题分区数最多相差一个；

分区的分配尽可能的与上次分配的保持相同。（遇到一个消费者挂掉的情况

,会把挂掉消费者上的分区再分配，而不是全部重新分配）

---