如何确定 Kafka 集群大小
How to decide Kafka Cluster size
我打算决定 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，这些是我的观察结果。
每个topic被划分为partitions，一个topic的所有partitions分布在kafka broker上；首先，这些有助于保存大小大于单个 kafka 代理容量的主题，并且它们还增加了消费者并行度。
为了提高可靠性和容错性，进行了分区复制，它们不会增加消费者并行度。经验法则是单个代理每个分区只能托管一个副本。因此经纪人数量必须>=副本数量
所有分区都分布在所有可用的代理中，分区的数量可以与代理的数量无关，但分区的数量必须等于消费者组中的消费者线程的数量（以获得最佳吞吐量）
在确定集群大小时，应牢记您希望在消费者处实现的吞吐量。
据我了解，从 Kafka 获得良好的吞吐量并不仅仅取决于集群的大小；还有其他配置也需要考虑。我会尽量分享。
Kafka 的吞吐量应该与您拥有的磁盘数量成线性关系。 Kafka 0.8 中引入的新的多数据目录特性允许 Kafka 的主题在不同的机器上有不同的分区。随着分区数量的大幅增加，领导者选举过程变慢的可能性也会增加，这也会影响消费者的再平衡。这是需要考虑的事情，可能是一个瓶颈。
另一个关键可能是磁盘刷新率。由于 Kafka 总是立即将所有数据写入文件系统，因此数据刷新到磁盘的频率越高，Kafka 的 "seek-bound" 就会越多，吞吐量就越低。同样，非常低的刷新率可能会导致不同的问题，因为在这种情况下要刷新的数据量会很大。所以提供一个确切的数字不是很实际，我认为这就是你在 Kafka 文档中找不到这样直接答案的原因。
还会有其他因素。例如消费者的 fetch 大小、压缩、异步生产者的批量大小、套接字缓冲区大小等
硬件和 OS 也将在这方面发挥关键作用，因为在基于 Linux 的环境中使用 Kafka 是可取的，因为它具有用于将数据写入磁盘的 pageCache 机制。阅读更多相关内容 here
在实际调整它以满足您的需要之前，您可能还想看一下 how OS flush behavior play a key role into consideration。我认为理解设计理念是关键，这使得它在吞吐量和容错方面非常有效。
一些我觉得有用的资源可以挖掘
- https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
- http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
- https://grey-boundary.io/load-testing-apache-kafka-on-aws/
- https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing
每个经纪人的总数 MB/s 为：
Data/Day = (100×10^6 条消息/天) × 0.5MB = 5TB/天每个主题
这给了我们 ~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, which I personally favor a lot since it does an amazing work with processing real-time streams
是一款管理您的 kafka 监视器和流的好软件
我打算决定 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，这些是我的观察结果。
每个topic被划分为partitions，一个topic的所有partitions分布在kafka broker上；首先，这些有助于保存大小大于单个 kafka 代理容量的主题，并且它们还增加了消费者并行度。
为了提高可靠性和容错性，进行了分区复制，它们不会增加消费者并行度。经验法则是单个代理每个分区只能托管一个副本。因此经纪人数量必须>=副本数量
所有分区都分布在所有可用的代理中，分区的数量可以与代理的数量无关，但分区的数量必须等于消费者组中的消费者线程的数量（以获得最佳吞吐量）
在确定集群大小时，应牢记您希望在消费者处实现的吞吐量。
据我了解，从 Kafka 获得良好的吞吐量并不仅仅取决于集群的大小；还有其他配置也需要考虑。我会尽量分享。
Kafka 的吞吐量应该与您拥有的磁盘数量成线性关系。 Kafka 0.8 中引入的新的多数据目录特性允许 Kafka 的主题在不同的机器上有不同的分区。随着分区数量的大幅增加，领导者选举过程变慢的可能性也会增加，这也会影响消费者的再平衡。这是需要考虑的事情，可能是一个瓶颈。
另一个关键可能是磁盘刷新率。由于 Kafka 总是立即将所有数据写入文件系统，因此数据刷新到磁盘的频率越高，Kafka 的 "seek-bound" 就会越多，吞吐量就越低。同样，非常低的刷新率可能会导致不同的问题，因为在这种情况下要刷新的数据量会很大。所以提供一个确切的数字不是很实际，我认为这就是你在 Kafka 文档中找不到这样直接答案的原因。
还会有其他因素。例如消费者的 fetch 大小、压缩、异步生产者的批量大小、套接字缓冲区大小等
硬件和 OS 也将在这方面发挥关键作用，因为在基于 Linux 的环境中使用 Kafka 是可取的，因为它具有用于将数据写入磁盘的 pageCache 机制。阅读更多相关内容 here
在实际调整它以满足您的需要之前，您可能还想看一下 how OS flush behavior play a key role into consideration。我认为理解设计理念是关键，这使得它在吞吐量和容错方面非常有效。
一些我觉得有用的资源可以挖掘
- https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
- http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
- https://grey-boundary.io/load-testing-apache-kafka-on-aws/
- https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing
每个经纪人的总数 MB/s 为：
Data/Day = (100×10^6 条消息/天) × 0.5MB = 5TB/天每个主题
这给了我们 ~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, which I personally favor a lot since it does an amazing work with processing real-time streams
是一款管理您的 kafka 监视器和流的好软件