Kafka 拓扑最佳实践 [英] Kafka Topology Best Practice

问题描述

我有 4 台机器，其中 Kafka 集群配置了拓扑每台机器有一个动物园管理员和两个经纪人.

I have 4 machines where a Kafka Cluster is configured with topology that each machine has one zookeeper and two broker.

对于这种配置，您对最大化主题和分区以获得最佳性能有何建议?

With this configuration what do you advice for maximum topic&partition for best performance?

复制因子 3:使用 kafka 0.10.XX

Replication Factor 3: using kafka 0.10.XX

谢谢?

推荐答案

无论有多少节点，每个主题都限制在 100,000 个分区(截至 2017 年 7 月)

Each topic is restricted to 100,000 partitions no matter how many nodes (as of July 2017)

至于主题的数量取决于机器上最小的 RAM 有多大.这是因为 Zookeeper 将所有内容都保存在内存中以便快速访问(它也不对 znode 进行分片，只是在写入时跨 ZK 节点进行复制).这实际上意味着一旦您耗尽一台机器的内存，ZK 将无法添加更多主题.在 Kafka 代理节点上达到此限制之前，您很可能会用完文件句柄.

As to the number of topics that depends on how large the smallest RAM is across the machines. This is due to Zookeeper keeping everything in memory for quick access (also it doesnt shard the znodes, just replicates across ZK nodes upon write). This effectively means once you exhaust one machines memory that ZK will fail to add more topics. You will most likely run out of file handles before reaching this limit on the Kafka broker nodes.

在他们的网站上引用 KAFKA 文档(6.1 Basic Kafka Operations https://kafka.apache.org/documentation/#basic_ops_add_topic):

To quote the KAFKA docs on their site (6.1 Basic Kafka Operations https://kafka.apache.org/documentation/#basic_ops_add_topic):

每个分片分区日志都放在自己的Kafka日志目录下的文件夹中.此类文件夹的名称由主题名称、短划线 (-) 和分区 ID 组成.由于典型的文件夹名称长度不能超过 255 个字符，因此主题名称的长度会有限制.我们假设分区数永远不会超过 100,000.因此，主题名称不能超过 249 个字符.这会在文件夹名称中为破折号和可能的 5 位长分区 ID 留出足够的空间.

Each sharded partition log is placed into its own folder under the Kafka log directory. The name of such folders consists of the topic name, appended by a dash (-) and the partition id. Since a typical folder name can not be over 255 characters long, there will be a limitation on the length of topic names. We assume the number of partitions will not ever be above 100,000. Therefore, topic names cannot be longer than 249 characters. This leaves just enough room in the folder name for a dash and a potentially 5 digit long partition id.

引用 Zookeeper 文档 (https://zookeeper.apache.org/doc/trunk/zookeeperOver.html):

To quote the Zookeeper docs (https://zookeeper.apache.org/doc/trunk/zookeeperOver.html):

复制的数据库是包含整个数据树的内存数据库.更新会记录到磁盘以实现可恢复性，并且写入会在应用到内存数据库之前序列化到磁盘.

The replicated database is an in-memory database containing the entire data tree. Updates are logged to disk for recoverability, and writes are serialized to disk before they are applied to the in-memory database.

性能:

根据您的发布和消费语义，主题分区的有限性会发生变化.以下是您应该问自己的一组问题，以深入了解潜在的解决方案(您的问题非常开放):

Depending on your publishing and consumption semantics the topic-partition finity will change. The following are a set of questions you should ask yourself to gain insight into a potential solution (your question is very open ended):

• 我发布的数据是否对任务至关重要(即不能丢失，必须确保我发布了它，必须恰好使用一次)?
• 我应该让 producer.send() 调用尽可能同步，还是继续使用异步方法和批处理(我是否需要权衡发布速度的保证)?
• 我发布的消息是否相互依赖?消息 A 是否必须在消息 B 之前被消费(意味着 A 在 B 之前发布)?
• 如何选择要将消息发送到哪个分区?我应该:将消息分配给一个分区(额外的生产者逻辑)，让集群以循环方式决定，还是分配一个将散列到主题分区之一的键(需要提出均匀分布的散列)以获得良好的跨分区负载平衡)
• 您应该有多少个主题?这与您数据的语义有何联系?为许多不同的逻辑数据域自动创建主题是否有效(想想对 Zookeeper 的影响和删除陈旧主题的管理痛苦)?
• 分区提供并行性(可能有更多消费者)并可能增加积极的负载平衡效果(如果生产者发布正确).您是否希望将问题域元素的一部分分配给特定分区(在将客户端 A 的发送数据发布到分区 1 时)?这有什么副作用(想想可重构性和可维护性)?
• 您是否想要创建比您需要的更多的分区，以便在需要时可以扩展到更多的代理/消费者?鉴于您的专业知识，KAFKA 集群的自动扩展有多现实?这会手动完成吗?手动扩展对于您的问题域是否可行(您是围绕具有众所周知特征的固定系统构建 KAFKA，还是需要能够处理消息中的严重峰值)?
• 我的消费者将如何订阅主题?他们会使用预先配置的配置还是使用正则表达式来消费许多主题?主题之间的消息是相关的还是优先的(需要消费者的额外逻辑来实现优先级)?
• 您是否应该使用不同的网络接口在代理之间进行复制(即，生产者/消费者使用端口 9092，复制流量使用端口 9093)?

好的链接:

http://cloudurable.com/ppt/4-kafka-detailed-architecture.pdfhttps://www.slideshare.net/ToddPalino/putting-kafka-into-超速行驶https://www.slideshare.net/江杰琴/no-data-loss-pipeline-with-apache-kafka-49753844https://kafka.apache.org/documentation/

这篇关于Kafka 拓扑最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！