干货满满！关于Kafka 负载均衡在 vivo 的落地实践

vivo 互联网服务器团队-You Shuo

副本迁移是Kafka最高频的操作，对于一个拥有几十万个副本的集群，通过人工去完成副本迁移是一件很困难的事情。Cruise Control作为Kafka的运维工具，它包含了Kafka 服务上下线、集群内负载均衡、副本扩缩容、副本缺失修复以及节点降级等功能。显然，Cruise Control的出现，使得我们能够更容易的运维大规模Kafka集群。
备注：本文基于 Kafka 2.1.1开展。

一、 Kafka 负载均衡

1.1 生产者负载均衡

Kafka 客户端可以使用分区器依据消息的key计算分区，如果在发送消息时未指定key，则默认分区器会基于round robin算法为每条消息分配分区；

否则会基于murmur2哈希算法计算key的哈希值，并与分区数取模的到最后的分区编号。

很显然，这并不是我们要讨论的Kafka负载均衡，因为生产者负载均衡看起来并不是那么的复杂。

1.2 消费者负载均衡

考虑到消费者上下线、topic分区数变更等情况，KafkaConsumer还需要负责与服务端交互执行分区再分配操作，以保证消费者能够更加均衡的消费topic分区，从而提升消费的性能；

Kafka目前主流的分区分配策略有2种(默认是range，可以通过
partition.assignment.strategy参数指定)：

• range: 在保证均衡的前提下，将连续的分区分配给消费者，对应的实现是RangeAssignor；
• round-robin：在保证均衡的前提下，轮询分配，对应的实现是RoundRobinAssignor；
• 0.11.0.0版本引入了一种新的分区分配策略StickyAssignor，其优势在于能够保证分区均衡的前提下尽量保持原有的分区分配结果，从而避免许多冗余的分区分配操作，减少分区再分配的执行时间。

无论是生产者还是消费者，Kafka 客户端内部已经帮我们做了负载均衡了，那我们还有讨论负载均衡的必要吗？答案是肯定的，因为Kafka负载不均的主要问题存在于服务端而不是客户端。

二、 Kafka 服务端为什么要做负载均衡

我们先来看一下Kafka集群的流量分布（图1）以及新上线机器后集群的流量分布（图2）：

 

从图1可以看出资源组内各broker的流量分布并不是很均衡，而且由于部分topic分区集中分布在某几个broker上，当topic流量突增的时候，会出现只有部分broker流量突增。

这种情况下，我们就需要扩容topic分区或手动执行迁移动操作。

图2是我们Kafka集群的一个资源组扩容后的流量分布情况，流量无法自动的分摊到新扩容的节点上。此时，就需要我们手动的触发数据迁移，从而才能把流量引到新扩容的节点上。

2.1 Kafka 存储结构

为什么会出现上述的问题呢？这个就需要从Kafka的存储机制说起。

下图是Kafka topic的存储结构，其具体层级结构描述如下：

1. 每个broker节点可以通过logDirs配置项指定多个log目录，我们线上机器共有12块盘，每块盘都对应一个log目录。
2. 每个log目录下会有若干个[topic]-[x]字样的目录，该目录用于存储指定topic指定分区的数据，对应的如果该topic是3副本，那在集群的其他broker节点上会有两个和该目录同名的目录。
3. 客户端写入kafka的数据最终会按照时间顺序成对的生成.index、.timeindex、.snapshot以及.log文件，这些文件保存在对应的topic分区目录下。
4. 为了实现高可用目的，我们线上的topic一般都是2副本/3副本，topic分区的每个副本都分布在不同的broker节点上，有时为了降低机架故障带来的风险，topic分区的不同副本也会被要求分配在不同机架的broker节点上。

了解完Kafka存储机制之后，我们可以清晰的了解到，客户端写入Kafka的数据会按照topic分区被路由到broker的不同log目录下，只要我们不人工干预，那每次路由的结果都不会改变。因为每次路由结果都不会改变，那么问题来了：

随着topic数量不断增多，每个topic的分区数量又不一致，最终就会出现topic分区在Kafka集群内分配不均的情况。

比如：topic1是10个分区、topic2是15个分区、topic3是3个分区，我们集群有6台机器。那6台broker上总会有4台broker有两个topic1的分区，有3台broke上有3个topic3分区等等。

这样的问题就会