如何确定 Kafka 集群大小答案

【问题标题】：How to decide Kafka Cluster size如何确定 Kafka 集群大小
【发布时间】：2015-03-11 10:53:08
【问题描述】：

我计划决定 Kafka 集群上应该存在多少个节点。我不确定要考虑的参数。我确信它必须 >=3（复制因子为 2，容错率为 1 个节点）。

谁能告诉我在决定集群大小以及它们如何影响大小时应该记住哪些参数。

我知道以下因素，但不知道它如何从数量上影响集群大小。我知道它如何定性地影响集群大小。还有其他影响集群大小的参数吗？ 1. Replication factor (cluster size >= replication factor) 2. Node failure tolerance. (cluster size >= node-failure + 1)

在考虑所有参数的情况下，以下场景的集群大小应该是多少 1. There are 3 topics. 2. Each topic has messages of different size. Message size range is 10 to 500kb. Average message size being 50kb. 3. Each topic has different partitions. Partitions are 10, 100, 500 4. Retention period is 7 days 5. There are 100 million messages which gets posted every day for each topic.

有人可以将我指向相关文档或任何其他可能讨论此问题的博客。我已经google了，但是没有用

【问题讨论】：

我想自己接电话。我想知道我们决定集群大小的基础上是否有任何参数。 Kafka 文档没有提供有关最佳集群大小的任何信息。将在其周围添加数据点。

标签： distributed apache-kafka

【解决方案1】：

我最近使用过 kafka，这些是我的观察结果。

每个topic被划分为partition，一个topic的所有partition都分布在kafka brokers上；首先，这些有助于保存大小大于单个 kafka 代理容量的主题，并且它们还增加了消费者并行度。

为了提高可靠性和容错性，会进行分区复制，但不会增加消费者的并行度。经验法则是单个代理每个分区只能托管一个副本。因此，代理数量必须 >= 副本数量

所有分区都分布在所有可用的代理上，分区的数量可以与代理的数量无关，但分区的数量必须等于消费者组中的消费者线程数（以获得最佳吞吐量）

在决定集群大小时，应牢记您希望在消费者处实现的吞吐量。

【讨论】：

为了实现高消费者吞吐量，即以高速率消费消息，增加分区数量并触发线程数量等于高级消费者中的分区数量。
@nitin 如果你有 1000 个分区并且想要从所有分区运行消费者到消费者消息会发生什么？？？
设计一个有1000个线程的高级消费者，每个线程消费一个分区。有关详细信息，请参阅此链接中的“设计高级消费者” --> cwiki.apache.org/confluence/display/KAFKA/…
根据我的研究，增加分区对性能的影响大于集群大小。如果您将分区数量增加到 1000，您应该小心消费者。如果所有消费者都在同一台机器上运行，可能会有点担心（因为将产生 1000 个新线程）。如果您的机器足够好就可以了，否则您需要在多台机器上运行消费者（具有相同的消费者组）
leonardo 提到的 @user2720864 使用相同的消费者组运行多台机器。应该通过记住主题的大小并平衡它对代理的负载来决定分区的数量。是的，更多的分区会增加消费者的吞吐量，但分配大量的分区会导致非常少的数据/分区和更多的线程开销

【解决方案2】：

据我了解，从 Kafka 获得良好的吞吐量并不仅仅取决于集群的大小。还有其他配置也需要考虑。我会尽量分享。

Kafka 的吞吐量应该随着您拥有的磁盘数量线性扩展。 Kafka 0.8 中引入的新的多数据目录功能允许 Kafka 的主题在不同的机器上具有不同的分区。随着分区数量的大幅增加，leader 选举过程会变慢的机会也会增加，这也会影响消费者的再平衡。这是需要考虑的问题，可能会成为瓶颈。

另一个关键可能是磁盘刷新率。由于 Kafka 总是立即将所有数据写入文件系统，数据刷新到磁盘的频率越高，Kafka 的“seek-bound”就越多，吞吐量就越低。同样，非常低的刷新率可能会导致不同的问题，因为在这种情况下要刷新的数据量会很大。所以提供一个准确的数字并不是很实用，我认为这就是你在 Kafka 文档中找不到这样直接答案的原因。

还有其他因素。例如消费者的fetch 大小、压缩、异步生产者的批量大小、套接字缓冲区大小等。

硬件和操作系统也将在这方面发挥关键作用，因为在基于 Linux 的环境中使用 Kafka 是可取的，因为它具有用于将数据写入磁盘的 pageCache 机制。阅读更多关于here

在实际调整它以满足您的需求之前，您可能还想看看how OS flush behavior play a key role into consideration。我相信理解设计理念是关键，这使得它在吞吐量和容错方面如此有效。

一些我觉得有用的资源

【讨论】：

【解决方案3】：

每个代理的总 MB/s 为：

数据/天 = (100×10^6 条消息/天) × 0.5MB = 5TB/天/主题

这为我们提供了每个 Broker 约 58MB/s 的数据。假设消息在分区之间平均分配，对于我们得到的整个集群：58MB/s x 3 Topics = 178MB/s 对于所有集群。

现在，对于复制，您有：每个主题 1 个额外的副本。因此，这变为 58MB/sec/broker INCOMING 原始数据 + 58MB/sec/broker OUTGOING 复制数据 + 58MB/sec/broker INCOMING 复制数据。

每个代理入口约为 136MB/s，每个代理出口约为 58MB/s。

系统负载会变得非常高，这还没有考虑任何流处理。

可以通过增加代理的数量并将您的主题拆分到更具体的分区来处理系统负载。如果您的数据非常重要，那么您可能需要不同的（高）复制因子。容错性也是决定复制的重要因素。
例如，如果您有非常重要的数据，除了管理您的分区的 N 个活动代理（带有副本）之外，您可能需要在不同区域添加备用跟随者。如果您需要非常低的延迟，那么您可能希望进一步增加您的分区（通过添加额外的键）。您拥有的密钥越多，每个分区上的消息就越少。对于低延迟，您可能需要一个仅管理该特殊主题且不对其他主题进行额外计算的新集群（带有副本）。如果某个主题不是很重要，那么您可能希望降低该特定主题的复制因子，并对某些数据丢失更具弹性。在构建 Kafka 集群时，支持您的基础设施的机器应该具备同样的能力。那是因为分区是以循环方式完成的，您希望每个代理能够处理相同的负载，因此消息的大小无关紧要。

流处理的负载也会产生直接影响。 Lenses 是一个很好的管理你的 kafka 监视器和管理你的流的软件，我个人非常喜欢它，因为它与 processing real-time streams 做了一个了不起的工作

【讨论】：