我计划决定Kafka Cluster上应该有多少个节点。我不确定要考虑的参数。我确信它必须是＆gt; = 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.
有人可以请我参阅相关文档或任何其他可能讨论此内容的博客。我有谷歌搜索它但无济于事
答案 0 :(得分：19)
据我所知，从Kafka获得良好的吞吐量并不仅仅依赖于群集大小;还有其他配置也需要考虑。我将尝试尽可能多地分享。
Kafka的吞吐量应该是线性scalabale与您拥有的磁盘数量。 Kafka 0.8中引入的新的多数据目录功能允许Kafka的主题在不同的机器上具有不同的分区。随着分区数量的大幅增加，领导者选举过程的机会也会越来越慢，这也会影响消费者的再平衡。这是需要考虑的事情，可能是瓶颈。
另一个关键因素可能是磁盘刷新率。由于Kafka总是立即将所有数据写入文件系统，数据刷新到磁盘的次数越多，Kafka的“搜索限制”就越多，吞吐量就越低。同样，非常低的刷新率可能导致不同的问题，因为在这种情况下，要刷新的数据量将很大。所以提供一个确切的数字是不太实际的，我认为这是你在Kafka文档中找不到这样直接答案的原因。
还会有其他因素。例如，消费者的fetch大小，压缩，异步生成器的批量大小，套接字缓冲区大小等。
硬件＆amp;操作系统也将在这方面发挥关键作用，因为在基于Linux的环境中使用Kafka是可取的，因为它的pageCache机制用于将数据写入磁盘。详细了解here
在实际调整之前，您可能还需要查看how OS flush behavior play a key role into consideration以满足您的需求。我认为理解设计理念是关键，这使得它在吞吐量和容错性方面非常有效。
答案 1 :(得分：2)
我最近和卡夫卡合作过，这些都是我的观察。
每个主题分为多个分区，主题的所有分区都分布在kafka代理中;首先，这些有助于保存大小超过单个kafka经纪商容量的主题，同时也增加了消费者的并行性。
为了提高可靠性和容错能力，需要对分区进行复制，并且不会增加消费者的并行度。拇指规则是单个代理只能为每个分区托管一个副本。因此，经纪人的数量必须> = =没有复制品
所有分区都分布在所有可用的代理中，分区数可以与代理的数量无关，但分区数必须等于使用者组中的使用者线程数（以获得最佳吞吐量）
应确定群集大小，同时牢记您希望在消费者处实现的吞吐量。
答案 2 :(得分：1)
每个代理的总MB / s为：
数据/天=（100×10 ^ 6消息/天）×0.5MB = 5TB /天每个主题
每个经纪人给我们带来58MB / s的速度。假设消息在分区之间平均分配，则对于整个群集，我们得到：58MB / s x 3主题= 178MB / s，适用于所有群集。
现在，对于复制，您具有：每个主题1个额外的副本。因此，这将成为58MB /秒/经纪人INCOMING复制数据+ 58MB / sec /经纪人即将复制数据+ 58MB / sec /经纪人INCOMING复制数据。
每个代理入口的速度约为〜136MB / s，每个代理出口的速度约为58MB / s。
系统负载将非常高，并且这不考虑任何流处理。
可以通过增加代理数量并将主题划分到更特定的分区来处理系统负载。
如果您的数据非常重要，则可能需要不同的（高）复制因子。容错也是决定复制的重要因素。
例如，如果您有非常重要的数据，除了管理分区的N个活动代理（带有副本）外，您可能需要在其他区域中添加备用关注者。
如果需要非常低的延迟，则可能需要进一步增加分区（通过添加其他键）。您拥有的键越多，每个分区上将拥有的消息越少。
对于低延迟，您可能需要一个仅管理该特殊主题的新集群（包含副本），而无需对其他主题进行任何额外的计算。
如果主题不是很重要，那么您可能希望降低该特定主题的复制因子，并且对某些数据丢失更具弹性。
在构建Kafka集群时，支持您的基础架构的机器应具有同等的能力。也就是说，由于分区是采用循环方式完成的，因此您希望每个代理都能够处理相同的负载，因此消息的大小无关紧要。
来自流处理的负载也将直接产生影响。 Lenses是一款管理kafka监视器并管理流的好软件，我个人非常喜欢它，因为它可以与processing real-time streams
一起出色地工作