如何找到 Kafka 集群的吞吐量极限？

Kafka 是很是流行的分布式流式处理和大数据消息队列解决方案，在技术行业已经获得了普遍采用，在 Dropbox 也不例外。Kafka 在 Dropbox 的不少分布式系统数据结构中发挥着重要的做用：数据分析、机器学习、监控、搜索和流式处理，等等。在 Dropbox，Kafka 集群由 Jetstream 团队负责管理，他们的主要职责是提供高质量的 Kafka 服务。他们的一个主要目标是了解 Kafka 在 Dropbox 基础设施中的吞吐量极限，这对于针对不一样用例作出适当的配置决策来讲相当重要。最近，他们建立了一个自动化测试平台来实现这一目标。这篇文章将分享他们所使用的方法和一些有趣的发现。

测试平台

上图描绘了本文所使用的测试平台的设置。咱们在 Spark 中使用 Kafka 客户端，这样就能够以任意规模生成和消费流量。咱们搭建了三个不一样大小的 Kafka 集群，要调整集群大小，只须要将流量重定向到不一样的集群。咱们建立了一个 Kafka 主题，用于生成测试流量。为简单起见，咱们将流量均匀地分布在 Kafka broker 之间。为实现这一目标，咱们建立了测试主题，分区数量是 broker 数量的 10 倍，这样每一个 broker 都是 10 个分区的首领。由于写入单个分区是串行的，因此若是每一个 broker 的分区太少会致使写入竞争，从而限制了吞吐量。根据咱们的实验，10 是一个恰到好处的数字，能够避免写入竞争形成吞吐量瓶颈。

因为基础设施的分布式特性，客户端遍及在美国的不一样地区。由于测试流量远低于 Dropbox 网络主干的限制，因此咱们能够安全地假设跨区域流量的限制也适用于本地流量。

是什么影响了工做负载？
有一系列因素会影响 Kafka 集群的工做负载：生产者数量、消费者群组数量、初始消费者偏移量、每秒消息数量、每条消息的大小，以及所涉及的主题和分区的数量，等等。咱们能够自由地设置参数，所以，颇有必要找到主导的影响因素，以便将测试复杂性下降到实用水平。

咱们研究了不一样的参数组合，最后得出结论，咱们须要考虑的主要因素是每秒产生的消息数（mps）和每一个消息的字节大小（bpm）。

流量模型
咱们采起了正式的方法来了解 Kafka 的吞吐量极限。特定的 Kafka 集群都有一个相关联的流量空间，这个多维空间中的每个点都对应一个 Kafka 流量模式，能够经过参数向量来表示：<mps、bpm、生产者数量、消费者群组数量、主题数量……>。全部不会致使 Kafka 过载的流量模式都造成了一个封闭的子空间，其表面就是 Kafka 集群的吞吐量极限。

对于初始测试，咱们选择将 mps 和 bpm 做为吞吐量极限的基础，所以流量空间就降到二维平面。这一系列可接受的流量造成了一个封闭的区域，找到 Kafka 的吞吐量极限至关于绘制出该区域的边界。

自动化测试
为了以合理的精度绘制出边界，咱们须要用不一样的设置进行数百次实验，经过手动操做的方式是不切实际的。所以，咱们设计了一种算法，无需人工干预便可运行全部的实验。

过载指示器
咱们须要找到一系列可以以编程方式判断 Kafka 健康情况的指标。咱们研究了大量的候选指标，最后锁定如下这些：

IO 线程空闲低于 20％：这意味着 Kafka 用于处理客户端请求的工做线程池太忙而没法处理更多工做负载。

同步副本集变化超过 50％：这意味着在 50％的时间内至少有一个 broker 没法及时复制首领的数据。

Jetstream 团队还使用这些指标来监控 Kafka 运行情况，当集群承受过大压力时，这些指标会首当其冲发出信号。

找到边界
为了找到一个边界点，咱们让 bpm 维度固定，并尝试经过更改 mps 值来让 Kafka 过载。当咱们有一个安全的 mps 值和另外一个致使集群接近过载的 mps 值时，边界就找到了。咱们将安全的值视为边界点，而后经过重复这个过程来找到整条边界线，以下所示：

值得注意的是，咱们调整了具备相同生产速率的生产者（用 np 表示），而不是直接调整 mps。主要是由于批处理方式致使单个生产者的生产速率不易控制。相反，改变生产者的数量能够线性地缩放流量。根据咱们早期的研究，单独增长生产者数量不会给 Kafka 带来明显的负载差别。

咱们经过二分查找来寻找单边界点。二分查找从一个很是大的 np[0,max] 窗口开始，其中 max 是一个确定会致使过载的值。在每次迭代中，选择中间值来生成流量。若是 Kafka 在使用这个值时发生过载，那么这个值将成为新的上限，不然就成为新的下限。当窗口足够窄时，中止该过程。咱们将对应于当前下限的 mps 值视为边界。

结果

咱们在上图中绘制了不一样大小的 Kafka 的边界。基于这个结果，咱们能够得出结论，Dropbox 基础设施能够承受的最大吞吐量为每一个 broker 60MB/s。

值得注意的是，这只是一个保守的极限，由于咱们测试用的消息大小彻底是随机的，主要是为了最小化 Kafka 内部消息压缩机制所带来的影响。在生产环境中，Kafka 消息一般遵循某种模式，由于它们一般由类似的过程生成，这为压缩优化提供了很大的空间。咱们测试了一个极端状况，消息所有由相同的字符组成，这个时候咱们能够看到更高的吞吐量极限。

此外，当有 5 个消费者群组订阅测试主题时，这个吞吐量限制仍然有效。换句话说，当读取吞吐量是当前 5 倍时，仍然能够实现这样的写入吞吐量。当消费者群组增长到 5 个以上时，随着网络成为瓶颈，写入吞吐量开始降低。由于 Dropbox 生产环境中的读写流量比远低于 5，因此咱们获得的极限适用于全部生产集群。

这个结果为未来的 Kafka 配置提供了指导基础。假设咱们容许最多 20％的 broker 离线，那么单个 broker 的最大安全吞吐量应为 60MB/s * 0.8 ~= 50MB/s。有了这个，咱们能够根据将来用例的估算吞吐量来肯定集群大小。

对将来工做的影响
这个平台和自动化测试套件将成为 Jetstream 团队的一笔宝贵的财富。当咱们切换到新硬件、更改网络配置或升级 Kafka 版本时，能够从新运行这些测试并得到新的吞吐量极限。咱们能够应用相同的方法来探索其余影响 Kafka 性能的因素。最后，这个平台能够做为 Jetstream 的测试平台，以便模拟新的流量模式或在隔离环境中重现问题。

总结在这篇文章中，咱们提出了一种系统方法来了解 Kafka 的吞吐量极限。值得注意的是，咱们是基于 Dropbox 的基础设施获得的这些结果，所以，因为硬件、软件栈和网络条件的不一样，咱们获得的数字可能不适用于其余 Kafka 实例。咱们但愿这里介绍的技术可以帮助读者去了解他们本身的 Kafka 系统。