在 Kafka 中,我只想使用一个代理、单个主题和一个分区,该分区具有一个生产者和多个消费者(每个消费者从代理获取自己的数据副本)。鉴于此,我不希望使用 Zookeeper 的开销;我不能只使用经纪人吗?为什么必须要有动物园管理员?
13 回答
是的,运行 Kafka 需要 Zookeeper。从 Kafka 入门文档:
第二步:启动服务器
Kafka 使用 zookeeper,所以如果你还没有 Zookeeper 服务器,你需要先启动一个 Zookeeper 服务器。您可以使用与 kafka 一起打包的便捷脚本来获得一个快速而肮脏的单节点 zookeeper 实例。
至于为什么,人们很久以前就发现你需要有一些方法来协调分布式系统中的任务、状态管理、配置等。一些项目已经建立了自己的机制(想想 MongoDB 分片集群中的配置服务器,或 Elasticsearch 集群中的主节点)。其他人选择利用 Zookeeper 作为通用分布式进程协调系统。所以 Kafka、Storm、HBase、SolrCloud 等等都使用 Zookeeper 来帮助管理和协调。
Kafka 是一个分布式系统,是为使用 Zookeeper 而构建的。您没有使用 Kafka 的任何分布式功能这一事实不会改变它的构建方式。无论如何,使用 Zookeeper 不应该有太多开销。一个更大的问题是你为什么要使用这种特殊的设计模式——Kafka 的单个代理实现错过了多代理集群的所有可靠性特性以及它的扩展能力。
正如其他人所解释的,如果没有 Zookeeper,Kafka(即使在最新版本中)也无法工作。
Kafka 将 Zookeeper 用于以下用途:
选举一个控制器。控制器是broker之一,负责维护所有分区的leader/follower关系。当一个节点关闭时,控制器会告诉其他副本成为分区领导者,以替换即将离开的节点上的分区领导者。Zookeeper 用于选举一个控制器,确保只有一个控制器,如果它崩溃,则选择一个新的控制器。
集群成员- 哪些代理还活着并且是集群的一部分?这也是通过 ZooKeeper 管理的。
主题配置- 存在哪些主题,每个主题有多少个分区,副本在哪里,谁是首选领导者,为每个主题设置了哪些配置覆盖
(0.9.0) - 配额- 每个客户端允许读取和写入多少数据
(0.9.0) - ACL - 谁被允许读取和写入哪个主题(旧的高级消费者) - 存在哪些消费者组,谁是他们的成员以及每个组从每个分区获得的最新偏移量是多少。
[来自https://www.quora.com/What-is-the-actual-role-of-ZooKeeper-in-Kafka/answer/Gwen-Shapira ]
关于您的场景,只有一个代理实例和一个具有多个消费者的生产者,您可以使用推送器创建一个频道,并将事件推送到消费者可以订阅并处理这些事件的频道。 https://pusher.com/
重要更新 - 2019 年 8 月:
ZooKeeper 依赖将从 Apache Kafka 中移除。请参阅KIP-500中的高级讨论:将 ZooKeeper 替换为自我管理的元数据仲裁。
这些努力将需要一些 Kafka 版本和额外的 KIP。Kafka 控制器将接管当前 ZooKeeper 任务的任务。控制器将利用事件日志的优势,这是 Kafka 的核心概念。
新的 Kafka 架构的一些好处是架构更简单、易于操作和更好的可扩展性,例如允许“无限分区”。
2021 年 2 月更新
对于最新版本 (2.7.0),运行 Kafka 仍需要ZooKeeper ,但在不久的将来ZooKeeper 将被自我管理的元数据 Quorum 取代。
请参阅已接受的KIP-500中的详细信息。
一、现状
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 引入了可以与 KIP-500 之前和之后版本的 Kafka 共存的桥接版本的概念。Bridge 版本很重要,因为它们可以实现对后 ZooKeeper 世界的零停机升级。
参考:
恕我直言 Zookeeper 不是开销,而是让您的生活更轻松。
它基本上用于维护集群中不同节点之间的协调。Kafka 最重要的事情之一是它使用 zookeeper 定期提交偏移量,以便在节点故障的情况下,它可以从先前提交的偏移量恢复(想象你自己处理所有这些)。
Zookeeper 在服务于许多其他目的方面也起着至关重要的作用,例如领导者检测、配置管理、同步、检测新节点何时加入或离开集群等。
未来的 Kafka 版本计划删除 zookeeper 依赖,但目前它是其中不可或缺的一部分。
以下是他们的常见问题页面中的几行:
一旦 Zookeeper quorum 关闭,broker 可能会导致状态不佳,无法正常服务客户端请求等。虽然当 Zookeeper quorum 恢复时,Kafka broker 应该能够自动恢复到正常状态,但仍然存在一些极端情况他们做不到,需要进行艰难的杀戮和恢复才能使其恢复正常。因此,建议密切监视您的 zookeeper 集群并对其进行配置以使其具有性能。
有关更多详细信息,请查看此处
Zookeeper 是任何类型的分布式系统的集中和管理系统。分布式系统是运行在不同节点/集群(可能位于地理位置较远的位置)上但作为一个系统运行的不同软件模块。Zookeeper 促进节点之间的通信,在节点之间共享配置,它跟踪哪个节点是领导者,哪个节点加入/离开等。Zookeeper 是保持分布式系统健全并保持一致性的人。Zookeeper 基本上是一个编排平台。
卡夫卡是一个分布式系统。因此,它需要对其可能在地理上相距遥远(或不在)的节点进行某种编排。
除了通常的有效负载消息传输之外,kafka 中还会发生许多其他通信,例如
- 与请求集群成员资格的代理相关的事件。
- 与经纪人相关的事件可用。
- 获取引导配置设置。
- 与控制器和领导者更新相关的事件。
- 帮助状态更新,例如心跳更新。
Zookeeper 本身是一个由多个节点组成的分布式系统。Zookeeper 是用于维护此类元数据的集中服务。
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 不再需要 ZooKeeper
是的,Zookeeper 是为 Kafka 设计的。因为 Zookeeper 有责任管理 Kafka 集群。它有所有 Kafka 代理的列表。它会通知 Kafka,如果有任何代理关闭、分区关闭、新代理启动或分区启动。简而言之,ZK 让每个 Kafka 代理更新 Kafka 集群的当前状态。
然后每个 Kafka 客户端(生产者/消费者)都需要做的就是与任何单个代理连接,并且该代理具有由 Zookeeper 更新的所有元数据,因此客户端不必为代理发现而烦恼。
在没有 Zookeeper 的情况下运行 Kafka 的请求似乎很常见。Charlatan图书馆解决了这个问题。
根据描述,Charlatan 或多或少是 Zookeeper 的模拟,提供由其他工具或数据库支持的 Zookeeper 服务。
在处理 Charlatan 库的作者的主要产品时,我遇到了那个库;在那里它工作正常……
本文解释了 Zookeeper 在 Kafka 中的作用。它解释了 kafka 如何是无状态的,以及 zookeper 如何在 kafka(以及更多分布式系统)的分布式特性中发挥重要作用。
首先
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书中。图片来自本课程