《深入理解Kafka学习笔记：核心设计与实践原理》-第4章主题与分区_深入理解kafka核心设计与实践原理朱忠华-CSDN博客

第4章主题与分区

从Kafka的底层实现来说，主题和分区都是逻辑上的概念，分区可以有一至多个副本，每个副本对应一个日志文件，每个日志文件对应一至多个日志分段（LogSegment），每个日志分段还可以细分为索引文件、日志存储文件和快照文件等。

4.1 主题的管理

4.1.1 创建主题

方式一：kafka-topics.sh
未指定副本分配参数replica-assignment，按照内部逻辑计算副本分配方案

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic test --partitions 10 --replication-factor 3

指定副本分配参数replica-assignment，直接按照副本分配参数创建主题

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic test --replica-assignment 2:0,0:1,1:2,2:1

当topic名有“.” 时，会将"." 替换为“_” 例如：“topic.name_1” 会变成 “topic_name_1”
主题的命名同样不推荐（虽然可以这样做）使用双下画线“__”开头，因为以双下画线开头的主题一般看作Kafka的内部主题。

方式二：kafka.admin.TopicCommand 类
通过向 TopicCommand 类中传入一些关键参数，直接调用TopicCommand类中的main（）函数来直接管理主题。

方式三：KafkaAdminClient

方式四：ZooKeeper
创建主题时，实质是在ZooKeeper的/brokers/topics下创建与该主题对应的子节点和配置信息。因此，直接使用 ZooKeeper 的客户端在/brokers/topics节点下创建相应的主题节点并写入预先设定好的分配方案，这样就可以创建一个新的主题了。

4.1.2 分区副本的分配

生产者分区分配： 为生产者确定消息发往哪个分区。
消费者分区分配： 为消费者确定前往哪个分区取消息。
创建主题分区分配： 为主题确定在哪些节点broker创建哪些分区副本。

在创建主题时，如果使用了replica-assignment参数，那么就按照指定的方案来进行分区副本的创建；如果没有使用replica-assignment参数，那么就需要按照内部的逻辑来计算分配方案了。
内部分配逻辑按照机架信息划分成两种策略：未指定机架信息和指定机架信息。如果集群中所有的 broker 节点都没有配置broker.rack参数，或者使用disable-rack-aware参数来创建主题，那么采用的就是未指定机架信息的分配策略，否则采用的就是指定机架信息的分配策略。

4.1.3 查看主题

有两种命令：list、describe
list查找所有可用topic

bin/kafka-topics.sh --zookeeper localhost:2181/kafka -list

describe查看主题信息,不加具体主题topic，则查看所有主题的详细信息

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --describe --topic test

4.1.4 修改主题

当一个主题被创建之后，依然允许我们对其做一定的修改，比如修改分区个数、修改配置等，这个修改的功能就是由kafka-topics.sh脚本中的alter指令提供的。
下面是增加分区的命令

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3

上面这个命令会有告警信息，当主题中消息包含key时，根据key计算分区的行为会受到影响，原本发往分区0的消息会被发往分区1,2 对于基于key计算的主题而言，建议一开始设置好分区数量。

kafka只支持增加分区数而不支持减少分区数。
此功能完全可以实现，不过也会使代码的复杂度急剧增大。
考虑删除的分区中的消息如何处理，如果随着分区一起删除则消息的可靠性得不到保障，如果分散插入现有的分区，那么在消息量很大的时候，内部的数据复制会占用很大的资源，而且在复制期间，此主题的可用性又如何得到保障？如果直接存储到现有分区尾部，消息的时间戳就不会递增，如果分散插入现有的分区，内部的数据复制会占用很大的资源。与此同时，顺序性问题、事务性问题，以及分区和副本的状态机切换问题都是不得不面对的。
反观这个功能的收益点却是很低的，如果真的需要实现此类功能，则完全可以重新创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可。

4.1.5 配置主题

kafka-configs.sh 脚本是专门用来对配置进行操作的，这里的操作是指在运行状态下修改原有的配置，如此可以达到动态变更的目的。
kafka-configs.sh脚本包含变更配置alter和查看配置describe这两种指令类型。
增、删、改的行为都可以看作变更操作
kafka-configs.sh脚本可以支持操作主题topics、brokers、用户users和客户端clients一共4种类型的配置。

kafka-configs.sh脚本使用entity-type参数来指定操作配置的类型，并且使用entity-name参数来指定操作配置的名称。
比如查看主题topic-config的配置可以按如下方式执行：

bin/kafka-config.sh --zookeeper localhost:2181/kafka --describe --entity-type topics --entity-name test

增加配置命令:

bin/kafka-config.sh --zookeeper localhost:2181/kafka --alter --entity-type topics --entity-name test --add-config cleanup.policy=compact,max.message.bytes=10000

支持多个配置的操作，多个配置之间用逗号“，”
用kafka-configs.sh脚本配置时，实质是在ZooKeeper中创建一个命名形式为/config/＜entity-type＞/＜entity-name＞的节点，并将变更的配置写入这个节点，节点内容中property-name代表属性名，property-value代表属性值。
增加配置实际上是往节点内容中添加属性的键值对，修改配置是在节点内容中修改相应属性的属性值，删除配置是删除相应的属性键值对。
变更配置时还会在ZooKeeper中的/config/changes/节点下创建一个以“config_change_”为前缀的持久顺序节点（PERSISTENT_SEQUENTIAL）

4.1.7 删除主题

方式一：kafka-topics.sh脚本
kafka-topics.sh脚本中的delete指令就可以用来删除主题，比如删除一个主题topic-delete：

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --delete test --if-exists

必须将delete.topic.enable参数配置为true才能够删除主题，这个参数的默认值就是true，如果配置为false，那么删除主题的操作将会被忽略。
如果要删除的主题是 Kafka 的内部主题，那么删除时就会报错。截至 Kafka 2.0.0，Kafka的内部一共包含2个主题，分别为__consumer_offsets和__transaction_state。
方式二：zookeeper

在ZooKeeper中的/admin/delete_topics 路径下创建一个与待删除主题同名的节点，以此标记该主题为待删除的状态。
手动的方式来删除主题。主题中的元数据存储在 ZooKeeper 中的/brokers/topics 和/config/topics 路径下，主题中的消息数据存储在 log.dir 或log.dirs配置的路径下，我们只需要手动删除这些地方的内容即可。

4.2 初始化KafkaAdminClient

以程序调用API的方式对主题、broker、配置、ACL（Access Control List）管理。

4.2.1 基本使用

4.2.2 主题合法性验证

kafka-topics.sh脚本创建的方式一般由运维人员操作，普通用户无权过问。那么KafkaAdminClient就为普通用户提供了一个“口子”，或者将其集成到公司内部的资源申请、审核系统中会更加方便。
Kafka broker 端有一个这样的参数：create.topic.policy.class.name，默认值为null，它提供了一个入口用来验证主题创建的合法性。

4.3 分区的管理

4.3.1 优先副本的选举

优先副本： 一个分区副本集合的第一个副本称之为优先副本。比如主题 topic-partitions 中分区 0的AR集合列表（Replicas）为[1，2，0]，那么分区0的优先副本即为1。
优先副本的选举： 通过一定的方式促使优先副本选举为leader副本，以此来促进集群的负载均衡，这一行为也可以称为“分区平衡”。

为什么要做优先副本的选举？
从某种程度上说，broker 节点中 leader 副本个数的多少决定了这个节点负载的高低。如果leader分布过于集中，就会造成集群负载不均衡。为了让系统负载均衡，我们总是需要让leader副本尽可能均匀地分布到 Kafka 集群的各个broker节点上。kafka系统broker节点会出现异常，lead副本会常常变换，解决方式是把优先副本作为leader副本，维护优先副本在Kafka集群中均匀分布，就是维护leader副本在各节点的均匀性。

优先副本的选举的局限性：
分区平衡并不意味着Kafka集群的负载均衡，有些leader副本的负载很高，比如需要承载TPS为30000的负荷，而有些leader副本只需承载个位数的负荷。也就是说，就算集群中的分区分配均衡、leader 分配均衡，也并不能确保整个集群的负载就是均衡的。

如何实现优先副本的选举？

自动平衡
在 Kafka 中可以提供分区自动平衡的功能，与此对应的 broker 端参数是 auto.leader.rebalance.enable，此参数的默认值为true。在生产环境中不建议将设置为true，因为执行的时间无法自主掌控，这可能引起负面的性能问题，也有可能引起客户端一定时间的阻塞。
手动平衡(推荐)
Kafka中kafka-perferred-replica-election.sh脚本提供了对分区leader副本进行重新平衡的功能，还提供了path-to-json-file参数来小批量地对部分分区执行优先副本的选举操作。

4.3.2 分区重分配

分区重分配的原因
集群上线或下线broker节点都会影响整个集群的负载均衡:

当集群中的一个节点突然宕机下线时，Kafka 并不会将该节点失效的分区副本自动地迁移到集群中剩余的可用broker节点上，如果放任不管，则不仅会影响整个集群的均衡负载，还会影响整体服务的可用性和可靠性。
当集群新增broker节点时，之前的主题分区并不会自动分配到新加入的节点中，因为在它们被创建时还没有这个新节点，这样新节点的负载和原先节点的负载之间严重不均衡。

分区重分配的操作
Kafka提供了Kafka-reassign-partitions.sh脚本来对分区进行迁移。它可以在集群扩容、broker节点失效的场景下分区进行迁移。
kafka-reassign-partitions .sh 脚本的使用分为3个步骤
①首先创建需要一个包含主题清单的JSON 文件
②其次根据主题清单和 broker 点清单生成一份重分配方案，

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/kafka --generate --topics-to-move-json-file reassign.json --broker-list 0,2

③最后根据这份方案执行具体的重分配动作。

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181/kafka --execute --reassignment-json-file project.json

分区重分配的原理：
先通过控制器为每个分区添加新副本（增加副本因子），新的副本将从分区的leader副本那里复制所有的数据。根据分区的大小不同，复制过程可能需要花一些时间，因为数据是通过网络复制到新副本上的。在复制完成之后，控制器将旧副本从副本清单里移除（恢复为原先的副本因子数）。注意在重分配的过程中要确保有足够的空间。