pun*_*eet 21 distributed apache-kafka
我计划决定Kafka Cluster上应该有多少个节点.我不确定要考虑的参数.我确信它必须> = 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.
有人可以请我参考相关文档或可能讨论此问题的任何其他博客.我有谷歌搜索它但无济于事
use*_*864 20
据我所知,从Kafka获得良好的吞吐量并不仅仅取决于簇大小; 还有其他配置也需要考虑.我将尝试尽可能多地分享.
Kafka的吞吐量应该是线性scalabale与您拥有的磁盘数量.Kafka 0.8中引入的新的多数据目录功能允许Kafka的主题在不同的机器上具有不同的分区.随着分区数量的大幅增加,领导者选举过程的机会也会越来越慢,这也会影响消费者的再平衡.这是需要考虑的事情,可能是瓶颈.
另一个关键因素可能是磁盘刷新率.由于Kafka总是立即将所有数据写入文件系统,数据刷新到磁盘的次数越多,Kafka的"搜索限制"就越多,吞吐量就越低.同样,非常低的刷新率可能导致不同的问题,因为在这种情况下,要刷新的数据量将很大.所以提供一个确切的数字是不太实际的,我认为这是你在Kafka文档中找不到这样直接答案的原因.
还有其他因素.例如,消费者的fetch大小,压缩,异步生产者的批量大小,套接字缓冲区大小等.
硬件和操作系统也将在这方面发挥关键作用,因为在基于Linux的环境中使用Kafka是可取的,因为它的pageCache机制用于将数据写入磁盘.在这里阅读更多内容
在实际调整以满足您的需求之前,您可能还需要了解操作系统刷新行为如何发挥关键作用.我认为理解设计理念是关键,这使其在吞吐量和容错性方面非常有效.
我最近与 kafka 一起工作，这些是我的观察。
每个topic被划分为partition，一个topic的所有partition分布在kafka brokers上；首先，这些有助于保存大小大于单个 kafka broker 容量的主题，并且它们增加了消费者并行度。
为了提高可靠性和容错性，进行了分区的复制，并且它们不会增加消费者并行度。经验法则是单个代理每个分区只能托管一个副本。因此，代理数必须 >= 副本数
所有分区都分布在所有可用的代理上，分区的数量可以与代理的数量无关，但分区的数量必须等于消费者组中的消费者线程数（以获得最佳吞吐量）
确定集群大小时应牢记您希望在消费者处实现的吞吐量。
小智 5
每个代理的总 MB/s 为：
\n\n数据/天 = (100\xc3\x9710^6 条消息/天) \xc3\x97 0.5MB = 每个主题 5TB/天
\n\n这为每个代理提供了大约 58MB/s。假设消息在分区之间平均分配，对于整个集群，我们得到：所有集群的 58MB/sx 3 个主题 = 178MB/s。
\n\n现在，对于复制，您有： 每个主题 1 个额外副本。因此，这变为 58MB/秒/代理传入原始数据 + 58MB/秒/代理传出复制数据 + 58MB/秒/代理传入复制数据。
\n\n每个代理入口的速度约为 136MB/s，每个代理出口的速度约为 58MB/s。
\n\n系统负载将变得非常高，并且这是在不考虑任何流处理的情况下。
\n\n可以通过增加代理数量并将主题拆分到更具体的分区来处理系统负载。\n如果您的数据非常重要，那么您可能需要不同的（高）复制因子。容错能力也是决定复制的一个重要因素。
\n例如，如果您有非常非常重要的数据，除了管理分区的 N 个活动代理（带有副本）之外，您可能需要在不同区域添加备用关注者。\n如果您需要非常低的延迟，那么您可能想进一步增加分区（通过添加额外的键）。您拥有的键越多，每个分区上的消息就越少。\n为了实现低延迟，您可能需要一个仅管理该特殊主题的新集群（带有副本），而不会对其他主题进行任何额外计算。\n如果某个主题不是很重要，那么您可能希望降低该特定主题的复制因子，并对某些数据丢失更有弹性。\n在构建 Kafka 集群时，支持您的基础设施的机器应该具有同等能力。这是因为分区是通过循环方式完成的，您希望每个代理能够处理相同的负载，因此消息的大小并不重要。
流处理的负载也会产生直接影响。Lenses是一个管理 kafka 监视器和管理流的好软件，我个人非常喜欢它，因为它在处理实时流方面做得非常出色
\n| 归档时间： |
|
| 查看次数： |
23316 次 |
| 最近记录： |