Apache堆栈技术的广泛使用是一个明显的趋势。 卡夫卡走在流行的最前沿：如今，认识这样的消息代理的人可能超过了习惯于在卡夫卡一词旁边看到弗朗兹一词的人。
我们自己在我们的项目中积极使用这项技术。 但这总是很有趣，但是它对其他人又如何工作？ 如果这不仅是某人的实践中的一个例子，而且是对该技术的重点测试，那将非常有趣。 因此，我们翻译了一篇最近的文章，其中谈到了Dropbox如何凭经验搜索卡夫卡的机会和耐力极限的界限。 并找到了他想要的。
在Dropbox上探索Kafka的带宽限制Apache Kafka是一种流行的解决方案，用于分布式流和顺序处理大量数据。 它已在高科技行业中广泛使用，Dropbox也不例外。 Kafka在我们许多关键的分布式系统的数据结构中扮演着重要的角色-数据分析，机器学习，监视，检索和流处理（Cape）（仅是少数几个）。
在Dropbox，Kafka群集由Jetstream团队管理，Jetstream团队的主要职责是提供与Kafka相关的高质量服务。 了解Dropbox基础架构内的Kafka带宽限制对于正确决定如何在不同用例中分配资源至关重要，这是团队的首要目标之一。 我们最近创建了一个自动化测试平台来实现这一目标。 在本出版物中，我们希望分享我们的方法和发现。
测试平台
上图显示了我们用于此研究的测试平台的参数。 我们使用Spark托管Kafka客户，这使我们能够以任意数量产生和消费流量。 我们创建了三个大小不同的Kafka集群，因此从根本上减少了对集群大小的调整，从而可以将流量重定向到另一点。 Kafka为测试流量的生产和消费创建了一个主题。 为简单起见，我们将流量平均分配给所有经纪人。 为此，我们创建了一个测试主题，其中的部分数量是代理数量的十倍。 每个经纪人正好带领10个部门。 由于写入段是顺序的，因此分配给一个代理的分区太少会导致竞争性写入，从而限制了带宽。 我们的实验表明，10是消除与竞争录音相关的瓶颈困难的好数字。
由于我们基础设施的分布式性质，我们的客户位于美国的各个地区。 考虑到我们的测试流量远低于Dropbox干线通道的限制，因此我们可以放心地假设此区域间流量限制也适用于本地流量。
什么影响负载？有许多因素会影响Kafka集群的负载：生产者数量，消费者组数量，消费者的初始偏移量，每秒消息数量，每条消息的大小，涉及的主题和部分的数量。 这些只是其中的一些。 设置参数的自由度很高。 因此，我们需要找到主导因素，以将测试的复杂性降低到可接受的水平。
我们检查了我们认为合适的各种参数组合。 我们得出一个毫不奇怪的结论，应考虑的主要因素是负载的主要组成部分：每秒产生的消息数（s / s）和每条消息的字节数（b / s）。
交通模型我们采取了正式的方法来了解Kafka的局限性。 特定的Kafka群集具有相关的流量空间。 多维空间中的每个点对应于适用于Kafka的流量的唯一状态，并以参数向量的形式呈现：<s / s，b / s，＃个生产者，＃个消费者组，＃个主题，...>。 所有不会导致KafKa拥塞的流量状态会形成一个封闭的子空间，其表面将限制Kafka集群。
在我们的第一个测试中，我们选择s / s和b / s作为主要参数，并将流量空间缩减为二维平面。 允许流量的边界形成清晰的跟踪区域。 在我们的情况下，检测卡夫卡极限等于确定该区域的边界值。
测试自动化为了以足够的精度设置边界，需要使用各种参数进行数百次测试-手动进行测试非常不合理。 因此，我们开发了一种算法，可让您无需人工干预即可执行所有实验。
拥塞率找到一组指标以编程方式评估Kafka的状态非常重要。 我们研究了各种可能的指标，并以以下小样本为依据：
- 一个简单的I / O流低于20％：这意味着Kafka用于处理客户请求的工作流池太忙了，无法应付传入的任务。
- 同步副本集（ISR）的变化超过50％：这意味着，在观察到的时间的50％中使用流量时，至少一个代理没有时间来复制从其领导者收到的数据。
Jetstream中使用相同的指示器监视Kafka的状态，并作为群集过载的第一个警报信号。
寻找边界为了确定一个边界值，我们固定b / s，然后更改s / s使Kafka过载。 当我们知道安全s / s值并且接近安全s / s值但已经引起过载时，可以确定边界s / s值。 在这两个值中，安全s / s值作为边界值。 如下图所示，边界值的线是根据不同指标b / s的相似测试结果形成的：
值得注意的是，我们不是直接调节s / s，而是尝试了不同数量的具有相同生产速度的制造商，用np表示。 问题是消息的批处理使对单个制造商的生产速度的控制变得复杂。 相反，制造商数量的变化使您可以线性地改变流量。 根据我们的早期研究，制造商数量的简单增加不会在Kafka上造成明显的负载差异。
首先，我们使用二进制搜索找到一个单独的边界值。 搜索从非常大的范围np [0，max]开始，其中max是必然导致过载的值。 在每次迭代中，选择一个平均值来创建流量。 如果Kafka使用此值过载，则该平均值将成为新的上限； 否则，它将成为新的下限。 当范围足够狭窄时，搜索过程将停止。 然后，我们考虑s / s指标，这些指标与已确定的边界值的下边界有关。
结果
如上图所示，我们为不同大小的Kafka设置了边界值。 根据结果，我们得出的结论是，每个代理的Dropbox基础架构的最大可能吞吐量为60 Mb / s。
应该强调的是，这是一个保守的限制，因为我们的测试消息的内容尽可能地随机，以减少Kafka中内部消息压缩的影响。 当流量达到极限时，驱动器和网络都将得到充分利用。 在工作脚本中，Kafka消息通常对应于某种模式，因为它们通常由相似的算法形成。 这为优化消息压缩提供了大量机会。 我们测试了一种极端情况，即消息由单个字符组成，并且记录了更高的吞吐量，因为磁盘和网络不再是瓶颈。
此外，如果至少有5个消费者组订阅了受测主题，则这些吞吐量指标是正确的。 换句话说，当读取带宽是5倍大时，可以达到指示的记录带宽。 当使用者组的数量超过5个时，随着网络成为瓶颈，记录带宽开始下降。 由于在使用Dropbox生产集群的情况下读写流量的比率远小于5，因此获得的带宽扩展到了所有生产集群。
此结果将帮助您更好地计划未来Kafka的资源。 例如，如果我们要允许多达20％的所有代理脱机工作，则一个代理的最大安全带宽应为60 MB / s * 0.8〜= 50 Mb / s。 此后，此数字可用于确定群集的大小，具体取决于未来用例的计划吞吐量。
未来工作的工具该平台和自动化测试仪将是Jetstream团队未来工作的宝贵工具。 当我们转移到新硬件，更改网络配置或更新Kafka的版本时，我们可以简单地重新运行这些测试，并在新配置的允许限制范围内获取新数据。 我们可以采用相同的方法来研究可能以各种方式影响卡夫卡业绩的其他因素。 最后，该平台可以用作Jetstream测试平台，以模拟新的流量选项或在隔离的环境中重现问题。
总结一下在本文中，我们介绍了我们的系统方法来理解Kafka的局限性。 需要注意的是，我们已经基于Dropbox基础设施实现了这些结果，因此，由于硬件，软件和网络条件的差异，我们的数字可能不适用于其他Kafka安装。 我们希望这里介绍的方法可以帮助读者理解他们自己的系统。