【问题标题】:Is Zookeeper a must for Kafka? [closed]Zookeeper 是 Kafka 的必备工具吗? [关闭]
【发布时间】:2014-07-08 05:41:59
【问题描述】:

在 Kafka 中,我只想使用一个代理、一个主题和一个具有一个生产者和多个消费者的分区(每个消费者从代理获取自己的数据副本)。鉴于此,我不希望使用 Zookeeper 的开销;我不能只使用经纪人吗?为什么必须要有 Zookeeper?

【问题讨论】:

  • Kafka 最大的设计目标之一是集群部署。这就是他们正在解决的问题,为独立服务器制作无 zk 版本将是愚蠢的。我觉得 kafka 不是你工作的工具,但你最好只使用 vanilla 文件..
  • 我真的很想知道您最终确定了什么?由于您没有选择任何答案,我假设您对此有自己的解决方案。谢谢!
  • Jocko 是 Kafka 的 golang 实现,没有 zookeeper 依赖和单个二进制安装
  • Zookeeper 已被移除,请看下面的答案-stackoverflow.com/a/57328140/1699956
  • 只是补充一下,如果你读过 zookeeper 的工作,你就会明白 - Zookeeper is network coordinator in a distributed system. Use ZooKeeper extensively for discovery, resource allocation, leader election, and high priority notifications.

标签: partitioning apache-zookeeper producer-consumer apache-kafka broker


【解决方案1】:

是的,运行 Kafka 需要 Zookeeper。来自 Kafka 入门文档:

第 2 步:启动服务器

Kafka 使用 zookeeper,所以如果你需要先启动 zookeeper 服务器 你还没有。您可以使用便利脚本 用kafka打包得到一个又快又脏的单节点zookeeper 实例。

至于为什么,人们很久以前就发现您需要有某种方法来协调分布式系统中的任务、状态管理、配置等。一些项目已经建立了自己的机制(想想 MongoDB 分片集群中的配置服务器,或 Elasticsearch 集群中的主节点)。其他人选择利用 Zookeeper 作为通用分布式进程协调系统。所以 Kafka、Storm、HBase、SolrCloud 等等都使用 Zookeeper 来帮助管理和协调。

Kafka 是一个分布式系统,是为使用 Zookeeper 而构建的。您没有使用 Kafka 的任何分布式功能这一事实不会改变它的构建方式。无论如何,使用 Zookeeper 不应该有太多开销。一个更大的问题是您为什么要使用这种特殊的设计模式——Kafka 的单个代理实现错过了多代理集群的所有可靠性特性以及它的扩展能力。

【讨论】:

  • 事实上,kafka 的设计方式即使在你使用单个代理时仍然是分布式模式,但复制因子为 1——不会有捷径机制或特殊模式(实际上这很好)。
  • Kafka 0.8.1 需要 zk。我想知道,如果 Kafka 中没有抽象层与协调系统一起工作,那么其他协调系统如何启用 Kafka。
  • 您是否认为 Apache Zookeeper 可用于作为外部系统执行共识,如以下问题中所述? stackoverflow.com/q/70088996/5029509
【解决方案2】:

正如其他人所解释的,如果没有 Zookeeper,Kafka(即使在最新版本中也是如此)将无法工作。

Kafka 将 Zookeeper 用于以下用途:

选择控制器。控制器是broker之一,负责维护所有分区的leader/follower关系。当一个节点关闭时,控制器告诉其他副本成为分区领导者,以替换即将离开的节点上的分区领导者。 Zookeeper 用于选举一个控制器,确保只有一个控制器,如果它崩溃了,就选择一个新的控制器。

集群成员 - 哪些代理还活着并且是集群的一部分?这也是通过 ZooKeeper 管理的。

主题配置 - 存在哪些主题,每个主题有多少个分区,副本在哪里,谁是首选领导者,为每个主题设置了哪些配置覆盖

(0.9.0) - 配额 - 每个客户端允许读取和写入多少数据

(0.9.0) - ACLs - 谁可以读写哪个主题 (旧的高级消费者)- 存在哪些消费者组,他们的成员是谁以及每个组从每个分区获得的最新偏移量是多少。

[来自https://www.quora.com/What-is-the-actual-role-of-ZooKeeper-in-Kafka/answer/Gwen-Shapira]

关于你的场景,只有一个代理实例和一个生产者有多个消费者,你可以使用推送器创建一个频道,并将事件推送到消费者可以订阅并处理这些事件的频道。 https://pusher.com/

【讨论】:

【解决方案3】:

重要更新 - 2019 年 8 月:

将从 Apache Kafka 中移除 ZooKeeper 依赖项。请参阅KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum 中的高级讨论。

这些努力将需要一些 Kafka 版本和额外的 KIP。 Kafka 控制器将接管当前 ZooKeeper 任务的任务。控制器将利用事件日志的优势,这是 Kafka 的核心概念。

新的 Kafka 架构的一些好处是架构更简单、易于操作和更好的可扩展性,例如允许“无限分区”。

【讨论】:

  • 最后,Kafka 对 ZooKeeper 的依赖在最新的 2.8.0 版本中已经被移除,不过它仍然是一个抢先体验的特性。
  • 您是否认为 Apache Zookeeper 可用于作为外部系统执行共识,如以下问题中所述? stackoverflow.com/q/70088996/5029509
【解决方案4】:

2021 年 2 月更新

对于最新版本 (2.7.0),ZooKeeper 仍然是 required 用于运行 Kafka,但在不久的将来 ZooKeeper 将被替换为自我管理的元数据仲裁

在接受的KIP-500中查看详细信息。


1.当前状态

Kafka 使用 ZooKeeper 存储有关分区和代理的元数据,并选择一个代理作为 Kafka 控制器。

目前,移除对 ZooKeeper 的这种依赖的工作正在进行中(通过KIP-500)。

2。移除的利润

删除 Apache ZooKeeper 依赖项提供了三个明显的好处:

  • 首先,它通过在 Kafka 本身中整合元数据来简化架构,而不是在 Kafka 和 ZooKeeper 之间拆分。这提高了稳定性,简化了软件,并且更容易监控、管理和支持 Kafka。
  • 其次,它提高了控制平面的性能,使集群能够扩展到数百万个分区。
  • 最后,它允许 Kafka 为整个系统提供一个单一的安全模型,而不是为 Kafka 和 Zookeeper 分别提供一个安全模型。

3.路线图

ZooKeeper 预计将于 2021 年移除,并具有一些里程碑,体现在以下 KIP 中:

|   KIP   |                           Name                           |      Status      | Fix Version/s |
|:-------:|:--------------------------------------------------------:|:----------------:|---------------|
| KIP-455 | Create an Administrative API for Replica Reassignment    |     Accepted     | 2.6.0         |
| KIP-497 | Add inter-broker API to alter ISR                        |     Accepted     | 2.7.0         |
| KIP-543 | Expand ConfigCommand's non-ZK functionality              |     Accepted     | 2.6.0         |
| KIP-555 | Deprecate Direct ZK access in Kafka Administrative Tools |     Accepted     | None          |
| KIP-589 | Add API to update Replica state in Controller            |     Accepted     | 2.8.0         |
| KIP-590 | Redirect Zookeeper Mutation Protocols to The Controller  |     Accepted     | 2.8.0         |
| KIP-595 | A Raft Protocol for the Metadata Quorum                  |     Accepted     | None          |
| KIP-631 | The Quorum-based Kafka Controller                        | Under discussion | None          |

KIP-500 引入了bridge release的概念,它可以与 KIP-500 之前和之后的 Kafka 版本共存。 Bridge 版本很重要,因为它们可以实现对 ZooKeeper 后世界的零停机升级。

参考资料:

  1. KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
  2. Apache Kafka Needs No Keeper: Removing the Apache ZooKeeper Dependency
  3. Preparing Your Clients and Tools for KIP-500: ZooKeeper Removal from Apache Kafka

【讨论】:

  • 这里和existing answer by Kai有什么不同?
  • @Naman,谢谢!现在提供有关删除 ZooKeeper 的更多详细信息
  • 最后,Kafka 对 ZooKeeper 的依赖在最新的 2.8.0 版本中已经被移除,不过它仍然是一个抢先体验的特性。
  • 您是否认为 Apache Zookeeper 可用于作为外部系统执行共识,如以下问题中所述? stackoverflow.com/q/70088996/5029509
【解决方案5】:

Kafka 是为使用 Zookeeper 而构建的。没有什么可以逃避的。

Kafka 是一个分布式系统,使用 Zookeeper 来跟踪 kafka 集群节点的状态。它还跟踪 Kafka 主题、分区等。

看你的问题,看来你不需要卡夫卡。您可以使用任何支持 pub-sub 的应用程序,例如 Redis、Rabbit MQ 或托管解决方案,例如 Pub-nub

【讨论】:

【解决方案6】:

恕我直言 Zookeeper 不是开销,而是让您的生活更轻松。

它主要用于维护集群中不同节点之间的协调。 Kafka 最重要的事情之一是它使用 zookeeper 定期提交偏移量,以便在节点故障的情况下,它可以从先前提交的偏移量恢复(想象你自己处理所有这些)。

Zookeeper 在服务于许多其他用途方面也发挥着至关重要的作用,例如领导者检测、配置管理、同步、检测新节点何时加入或离开集群等。

未来的 Kafka 版本计划移除 zookeeper 依赖,但目前它已成为其中不可或缺的一部分。

以下是他们的常见问题页面中的几行:

一旦 Zookeeper quorum 关闭,broker 可能会导致状态不佳,无法正常服务客户端请求等。虽然当 Zookeeper quorum 恢复时,Kafka broker 应该能够自动恢复到正常状态,但仍然存在很少有他们无法做到的极端情况,并且需要进行艰难的杀戮和恢复才能使其恢复正常。因此,建议密切监视您的 zookeeper 集群并对其进行配置,以使其具有性能。

更多详情请查看here

【讨论】:

  • Zookeeper 真是头疼。在 HBase 中。在卡夫卡。在风暴。我知道 Kafka/ZK 中存在长期存在的错误,导致我的团队放弃了它,转而使用 RabbitMQ。安装 HBase 涉及处理 ZK 问题的时间。但是,您与 OP 相关的答案是正确的:需要 ZK。
  • 确实存在错误和版本兼容性问题(至少对于 Kafka 和 ZK),但 zookeeper 的主要目的是管理任何分布式系统所需的那些复杂任务。我同意管理和调整你的 zk集群确实需要一些努力,并且严重依赖 zk 可能不是一个明智的选择。可能这就是为什么 kafka 在以后的版本中试图减少 zk 依赖的原因。另一方面,我认为 RabitMQ 和 Kafka 有非常不同的设计理念,旨在解决不同的用例,但我认为这超出了本次讨论的范围 :)
  • 是的,kafka 更适合高负载场景。我们决定做 RabbitMQ 直到/除非我们明确需要这些优势。在 RabbitMQ 中编程也更容易:Kafka 存在困难的 scala 版本依赖关系。
  • IMHO zookeeper is not an overhead but makes your life a lot easier. -> 不是从管理员的角度来看的。 Zk 是一块落后的旧 Java 垃圾。例如,它有一个长期突出的错误,即它不遵守 dns 条目的 ttl,因此它不会重新解析条目。窗外是您的服务器交换可能性。我很乐意将它换成 etcd。
  • “我们决定使用 RabbitMQ,直到/除非我们明确需要这些优势”。希望我的团队能像这样开悟。恕我直言,我们显然没有足够高的负载来证明 Kafka 的合理性,但无论如何我们都在使用 Kafka :(
【解决方案7】:

Zookeeper 是任何类型的分布式系统的集中和管理系统。分布式系统是运行在不同节点/集群(可能在地理位置较远的位置)上但作为一个系统运行的不同软件模块。 Zookeeper 促进节点之间的通信,在节点之间共享配置,它跟踪哪个节点是领导者,哪个节点加入/离开等。Zookeeper 是保持分布式系统健全并保持一致性的人。 Zookeeper 基本上是一个编排平台。

Kafka 是一个分布式系统。因此它需要某种编排为其可能在地理上相距遥远(或不在)的节点。

【讨论】:

【解决方案8】:

是的,Zookeeper 是为 Kafka 设计的。因为 Zookeeper 有责任管理 Kafka 集群。它有所有 Kafka 代理的列表。它会通知 Kafka,如果任何代理关闭、分区关闭、新代理启动或分区启动。简而言之,ZK 让每个 Kafka 代理更新 Kafka 集群的当前状态。

然后每个 Kafka 客户端(生产者/消费者)都需要与任何单个代理连接,并且该代理具有由 Zookeeper 更新的所有元数据,因此客户端不必为代理发现而烦恼。

【讨论】:

【解决方案9】:

除了通常的有效载荷消息传输之外,kafka 中还会发生许多其他通信,例如

  • 与请求集群成员资格的代理相关的事件。
  • 与经纪人相关的事件可用。
  • 获取引导配置设置。
  • 与控制器和领导者更新相关的事件。
  • 帮助状态更新,如心跳更新。

Zookeeper 本身是一个由多个节点组成的分布式系统。 Zookeeper 是用于维护此类元数据的集中服务。

【讨论】:

【解决方案10】:

Apache Kafka v2.8.0 让您可以提前访问 KIP-500,从而消除 Zookeeper 对 Kafka 的依赖,这意味着它不再需要 Apache Zookeeper


相反,Kafka 现在可以在 Kafka Raft 元数据模式 (KRaft mode) 下运行,从而启用内部 Raft quorum。当 Kafka 在KRaft mode 中运行时,它的元数据不再存储在 ZooKeeper 上,而是存储在控制器节点的内部仲裁中。这意味着您甚至不再需要运行 ZooKeeper。

但请注意,v2.8.0 目前处于抢先体验阶段,您暂时不应在生产环境中使用无 Zookeeper 的 Kafka。


移除 ZooKeeper 依赖并将其替换为内部仲裁的一些好处:

  • 更高效,因为控制器不再需要在每次集群启动或控制器选举时与 ZooKeeper 通信以获取集群状态元数据
  • 更具可扩展性,因为新实现将能够支持KRaft mode 中的更多主题和分区
  • 更轻松的集群管理和配置,因为您不必再​​管理两个不同的服务
  • 单进程Kafka集群

更多详情可以阅读文章Kafka No Longer Requires ZooKeeper

【讨论】:

【解决方案11】:

This 文章解释了 Zookeeper 在 Kafka 中的作用。它解释了 kafka 如何是无状态的,以及 zookeper 如何在 kafka(以及更多分布式系统)的分布式特性中发挥重要作用。

【讨论】:

【解决方案12】:

在没有 Zookeeper 的情况下运行 Kafka 的请求似乎很常见。图书馆Charlatan 解决了这个问题。

根据描述,Charlatan 或多或少是对 Zookeeper 的模拟,提供由其他工具或数据库备份的 Zookeeper 服务。

我在处理 Charlatan 库的作者的主要产品时遇到了那个库;在那里它工作正常......

【讨论】:

【解决方案13】:

首先

Apache ZooKeeper 是一个分布式存储,用于以高可用的方式提供配置同步服务。 在最新版本的 Kafka 中,已完成工作以使客户端消费者不会将有关其使用消息(称为偏移)的信息存储到 ZooKeeper.This reduced usage did not get rid of the need for consensus and coordination in distributed systems however. 而 Kafka 提供 容错和弹性,需要一些东西来提供所需的协调,ZooKeeper 启用了整个系统的这一部分。

其次

就分区的领导者达成一致,是 ZooKeeper 在 Kafka 生态系统中的实际应用的一个例子。

Zookeeper would work if there was even a single broker. 

这些来自Kafka In Action 书。 图片来自this course

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-05-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多