深入理解kafka核心设计与实践原理_读书笔记_第4章 主题与分区

4.1主题的管理

    主题的管理包括创建主题、 查看主题信息、修改主题和删除主题等操作。

    可以通过 Kafka 提供的 kafka-topics.sh 脚本来执行。

4.1.1创建主题

    创建一个主题名为 topic-create 分区数为4  副本因子为3的主题
    
    bin/kafka-topics.sh --zookeeper localhost: 2181/kafka

    --create --topic topic-create --partitions 4 --replication-factor 2 

4.1.2 分区副本的分配

    在生产者和消费者中也都有分区分配的概念。

    生产者的分区分配是指为每条消息指定其所要发往的分区。

    消费者中的分区分配是指为消费者指定其可以消费消息的分区

    而这里的分区分配是指为集群制定创建主题时的分区副本分配方案，即在哪个 broker 中创建哪些分区的副本。
    
    在创建主题时，如果使用了 replica-assignment 参数，那么就按照指定的方案来进分区副本的创建；

    如果没有使用 replica-assignment 参数，那么就需要按照内部的逻辑来计算分配方案了 。

    内部分配逻辑按照机架信息划分成两种策略: 未指定机架信息 和 指定机架信息 

    如果集群中所有的 broker节点都没有配置broker.rack 参数，或者使用 disable-rack-aware 参数来创建建主题，

    那么采用的就是未指定机架信息的分配策略，否则采用的就是指定机架信息的分配策略

4.1.3 查看主题

    list  和 describe 可以查看主题信息

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

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

4.1.4修改主题

    alter 修改分区数、修改配置等等

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

        建议在开始就设置好分区数量，避免以后对其进行调整

Kafka 支持增加分区数而不支持减少分区数。 原因如下：

    按照 Kafka 现有的代码逻辑，此功能完全可以实现，不过也会使代码的复杂会急剧增大

     实现此功能需要考虑的因素很多，比如删除的分区中的消息该如何处理？

     如果随着分区一起消失则消息的可靠性得不到保障；

     如果需要保留则又需要考虑如何保留，直接存储到现有分区的尾部，消息的时间戳就不会递增，
     
     如此对于 Spark、Flink 类需要消息时间戳（事件时间）的组件将会受到影响；

     如果分散插入现有的分区，那么在消息量很大的时候，内部的数据复制会占用很大的资源，

     而且在复制期间，此主题的可用性又如何得到保障？

     与此同时，顺序性问题、事务性问题，以及分区和副本的状态机切换问题都是不得不面对的 

     反观这个功能的收益点却是很低的，如采真的需要实现此类功能，

     则完全可以重新创建一个分区数较小的主题，然后将现有主题中的消息按照既定的逻辑复制过去即可

4.1.5 配置管理

     kafka-config.sh 脚本是专门用来对配置进行操作的，

     这里的操作是在运行状下修改原有的配置 ，如此可以达到动态变更的目的

4.1.6 主题端参数

        具体见书

4.1.7 删除主题

1.delete命令

     kafka-topics.sh 脚本中的 delete命令 就可以用来删除主题

     bin/kafka-topics.sh --zookeeper localhost:2181/kafka -- delete --topic topic-create

     注意：必须将 delete.topic.enable 参数配置为 true 才能够删除主题

2.使用zk 删除主题

(1) 可以直接通过 ZooKeeper 客户端来删除主题

     使用 kafka-topics.sh 脚本删除主题的行为本质上 只是在 ZooKeeper中的 admin/delete_topics 路径下

     创建一个与待删除主题同名的节点，以标记该主题为待删除的状态。

     与创建 主题相同的是，真正删除主题的动作也是由 Kafka 的控制器负责完成的。

     使用ZooKeeper 客户端 zkCli.sh删除主题 topic-delete
         
         [zk : localhost : 2181/kafka (CONNECTED) 15] create /admin/delete_topics/topic -delete " "

(2) 手动的方式来删除主题

     主题中的元数据存储在 ZooKeeper 中的/brokers/topic 和／config/topics 路径下， 

     主题中的消息数据存储在log.dir 或者 log.dirs配置的路径下。只需要手动删除这些地方的内容即可。 
     
     下面的示例中演示了如何删除topic-delete主题。总共分3步骤，第一步和第二步可以互换。

         ① 删除ZooKeepe 中的节点/config/topics/topic-delete

             [zk:localhost:2181/kafka (CONNECTED) 7] rmr /config/topics/topic-delete

         ②删除ZooKeeper 中的节点／brokers/topic/pi ele 及其子 点。
             
             [zk:localhost:2181/kafka (CONNECTED ) 8] delete /brokers/topics/topic-delete

         ③ 删除集群中有与主题topic-delete 有关的文件

             ＃集群中的各个broker 点中执 rm - rf /tmp/kafka-logs/topic-delete/＊
             
             [root@node1 kafka_2.11-2.0.0]# rm - rf /tmp/kafka-logs/topic-delete/*
             [root@node2 kafka 2.11-2.0.0]# rm - rf /tmp/kafka-logs/topic-delete/*
             [root@node3 kafka_2.11-2.0.0]# rm - rf /tmp/kafka-logs/topic-delete/*

4.2 初始化KafkaAdminClient

    一般情况下，我们都习惯使用 kafka-topic.sh 脚本来管理主题，

    但有些时候我 希望将主题管理类的功能集成到公司内部的系统中，

    打造集管理、监控、运维、告警为一体的生态平台，那么就需要以程序调用API方式去实现。

4.3 分区的管理

4.3.1 优先副本的选举

     为了能够有效治理负载失衡,Kafka引入了优先副本(preferred rep lica的概念。

     所谓的优先副本是指在 AR 集合列表中的第一个副本。 

     理想情况下，优先副本就是该分区的 leader 副本，所以也可以称之为preferred leader

     kafka 要确保所有主题的优先副本在Kafka集群中均匀分布，这样就保证了所有分区 leader均衡分布 
     
     所谓的优先副本选举是指通过一定的方式促使优先副本选举为leader，

     以此来促进集群的负载均衡， 这一行为也可以称为 "分区平衡"

4.3.2 分区自动平衡

     需要注意分区平衡并不意味着Kafka 集群 负载负载 ，因为还要考虑集群中的分区分配是否均衡。

     Kafka提供分区自动平衡的功能，对应的broker端参数是 auto.leader.rebalance.enable ，默认值true

     不过在生产环境中不建议将此参数设置为true，为这可能引起负面的性能问题，也有可能引起客户端一定时间的阻塞

     Kafka中kafka-perferred-replica election.sh 脚本提供了对分区 leader副本进行重新平衡的功能。

4.3.3 分区重分配

     Kafka提供了 kafka-reassign-partitions.sh脚本来执行分区重分配的工作，它可以在集群扩容、broker节点失效的场景下分区进行迁移。

     kafka-reassign-partitions .sh 脚本的使用分为3个步骤 

         ①首先创建需要一个包含主题清单的JSON 文件，

         ②其次根据主题清单和 broker 点清单生成一份重分配方案，
     
         ③最后根据这份方案执行具体的重分配动作。

4.3.4 复制限流

        todo

4.3.5 修改副本因子

    修改副本因子的功能也是通过重分配所使用的kafka-reassign-partition.sh脚本实现的

    副本数既可以增加，也可以减少。 但是分区数只能增加，不能减少。

4.4 如何选择合适的分区数

4.4.1 性能测试工具

    Kafka本身提供用于 生产者性能测试 kafka-producer-per-test.sh 

    用于消费者性能测试的 kafka-consumer-perf-test.sh

    命令如下
        bin/kafka-producer-perf-test.sh --topic topic-1 --num-records 1000000 --record-size 1024 --throughput -1 -- producer-props bootstrap.servers=localhost:9092 acks=1

        bin/kafka-consumer-perf-test.sh --topic topic-1 --messages 1000000 --broker-list localhost:9092

4.4.2 分区数越多吞吐量就越高吗

    一旦分区数超过了某个阔值之后，整体的吞吐量是不升反降的。
    
    也就是说，并不是分区数越多吞吐量也越大

4.4.3 分区数的选择

     如何选择合适的分区数？从某种意思来说，考验的是决策者的实战经验。

     更透彻地说，是对Kafka本身、业务应用、硬件资源、环境配置等多方面的考量而做出的选择。
     
     在设定完分区数，或者更确切地说是创建主题之后，还要对其追踪、监控、调优以求更好地利用它。
     
     一般情况下，根据预估的吞吐量及是否与 key 相关的规则来设定分区数即可，
     
     后期可以通过增加分区数、增加broker或分区重分配等手段来进行改进。

     如果一定要给一个准则，则建议将分区数设定为集群中 broker 的倍数，

     即假定集群中有3个broker节点，可以设定分区数为3、6、9 至于倍数的选定可以参考预估的吞吐量。

     不过，如果集群中的broker节点数有很多，

     比如大几十或上百上千，那么这种准则也不太适用，在选定分区数时步可以引入基架等参考因素