Topic和Partition

作用

主题作为消息的一级分类, 分区是对二级分类。分区是Kafka可伸缩性和水平扩展的关键, 也是多副本机制保证可用性的基础。分区可以有一到多个副本, 每个副本对应1个日志文件, 每个日志文件对应1到多个日志分段。每个日志分段又可以细分为日志文件, 索引文件和快照文件。

创建主题

参数有主题名称, 分区数量, 分区副本因子。显然主题名称是必须指定的, 分区数量和副本因子如不指定, 默认值都是1(测试玩玩可以, 生产别这么敷衍)。毕竟没有任何容错能力。如果有.或者_都会被替换为_, 最终可能会导致冲突, 这个kafka-topics.sh帮你做了处理。此外, Kafka会将分区尽可能分配在一个机架里, 与broker.rack参数有关。集群中的broker要么都指定rack, 要么都没有rack。负责创建主题失败。

副本位置

实际的日志文件数量=分区*副本因子, 这些日志文件应该放在哪个broker, 按照如下基本原则进行:

1. 每个broker上的副本不重复(副本放在一个节点, 节点宕机则分区全军覆没);
2. 每个broker上的副本数尽可能接近(副本的读写压力尽可能分摊);
   如果某个分区有数据倾斜(topic的某个副本消息特别多), 则可以手动指定broker节点进而均衡broker压力。

分区数量

如果topic的消息随着业务扩张增长存量的broker不堪重负, 我们就得向集群中加入新节点。但新节点默认情况下只会被增量topic使用, 存量topic不受影响。如果希望新节点承担负载, 则需要扩大存量topic的分区数量。然而, 扩大到多少是合理的则见仁见智。一般来说, 节点数固定的情况下, 存在一个相对理想的分区数, 超过之后吞吐量反而会下降。这需要基于实际场景测试获得。按照常规的读写分离理论, 应该扩大副本因子, 创建更多的副本。但在Kafka这里, 该方案没有存在的基础。这就是下面的优先副本。

数量参考

1. broker的整数倍, 节点非常多忽略;
2. 考虑机架因素;
3. 消息中key的规则设置;
4. 后续通过增加broker, 增加分区和分区重分配来进一步调整;

优先副本

Kafka分区的副本中, 只有leader副本对外提供读写服务, 其他follower副本仅作为冗余。因此当一个分区的leader副本不可用时, 该分区处于不可用状态, 此时Kafka会从副本集中选出新的leader副本再切换为可用状态。因此, 不严谨的角度来说, leader副本的多少决定了broker节点的负载。这也是增加节点后, 采用增加分区而不是扩大副本因子的原因。

鉴于此, 分区尽可能地均匀分布到broker节点上, 有利于leader副本的均匀分布, 进而有利于均衡broker节点的负载。从运维的角度来看, 我们需要一种干预手段来影响负载均衡的结果, 这就是Kafka的优先副本, 一般来说是分区的第一个副本。干预手段实际上就是尝试把优先副本选举为leader副本, 从而影响集群的负载情况。

小结

对于一个topic而言, 其相关的文件数量=分区*副本因子。而所有的副本中, 通常第一个副本为优先副本, 而实际对外提供读写服务的是leader副本。通过优先副本选举, 将优先副本重新选举为leader副本。站在集群视角, leader副本数量影响broker的负载, 我们需要重新调整分区数量, 或指定副本位置来平衡负载。