重要更新-2019年8月：
zookeeper依赖关系将从apache kafka中删除。请参阅kip-500中的高层讨论：将zookeeper替换为自我管理的元数据仲裁。
这些努力将需要一些Kafka释放和额外的基普。Kafka管制员将接管当前zookeeper任务的任务。控制器将利用事件日志的好处，这是Kafka的核心概念。
新kafka架构的一些好处是架构更简单、操作更容易、可扩展性更好，例如允许“无限分区”。

Kafka是用Zookeeper建造的。这是无法逃避的。
kafka是一个分布式系统，使用zookeeper跟踪kafka集群节点的状态。它还跟踪Kafka的主题、分区等。
看看你的问题，似乎你不需要Kafka。您可以使用任何支持pub-sub的应用程序（如redis、rabbit-mq）或托管解决方案（如pub-nub）。

是的，经营Kafka需要Zookeeper。Kafka入门文档：
第2步：启动服务器
Kafka使用zookeeper，所以如果你还没有zookeeper服务器，你需要先启动它。您可以使用kafka打包的方便脚本来获得一个快速而脏的单节点zookeeper示例。
至于原因，人们很久以前就发现，在分布式系统中，您需要某种方法来协调任务、状态管理、配置等。一些项目已经构建了自己的机制（比如mongodb分片集群中的配置服务器，或者elasticsearch集群中的主节点）。其他人选择利用zookeeper作为一个通用的分布式进程协调系统。所以Kafka、斯托姆、hbase、solrcloud等等都使用zookeeper来帮助管理和协调。
kafka是一个分布式系统，它是为使用zookeeper而构建的。事实上，您没有使用Kafka的任何分布式特性，这并不会改变它的构建方式。无论如何，使用zookeeper应该不会有太多开销。一个更大的问题是，为什么要使用这种特殊的设计模式——kafka的单个代理实现忽略了多代理集群的所有可靠性特性及其扩展能力。

本文阐述了动物管理员在Kafka中的角色。它解释了kafka是如何无状态的，zookeper如何在kafka的分布式特性（以及更多的分布式系统）中扮演重要角色。

正如其他人所解释的，Kafka（即使是最新版本）没有zookeeper也无法工作。
Kafka使用zookeeper进行以下操作：
选举控制人。控制器是代理之一，负责维护所有分区的领导者/追随者关系。当一个节点关闭时，是控制器告诉其他复制副本成为分区引线，以替换即将离开的节点上的分区引线。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]
对于您的场景，只有一个代理示例和一个生产者具有多个使用者，您可以使用pusher创建一个通道，并将事件推送到该通道，使用者可以订阅和传递这些事件。https://pusher.com/

是的，Zookeeper是Kafka设计的必备品。因为Zookeeper有责任管理一种Kafka集群。上面有所有Kafka经纪人的名单。它会通知kafka，如果任何代理出现故障，或者分区出现故障，或者新代理出现故障，或者分区出现故障。简言之，zk会让每个kafka代理更新kafka集群的当前状态。
然后，每个kafka客户机（生产者/消费者）所需要做的就是连接任何一个代理，并且该代理拥有zookeeper更新的所有元数据，所以客户机不必为代理发现而烦恼。

zookeeper是一个适用于任何分布式系统的集中管理系统。分布式系统是运行在不同节点/集群（可能位于地理位置较远的位置）上但作为一个系统运行的不同软件模块。zookeeper有助于节点之间的通信，共享节点之间的配置，它跟踪哪个节点是领导者，哪个节点加入/离开等。zookeeper是保持分布式系统正常和一致性的人。zookeeper基本上是一个编排平台。
Kafka是一个分布式系统。因此，它需要对其节点进行某种编排，这些节点可能在地理位置上很遥远（或者不遥远）。

除了通常的有效载荷消息传输之外，Kafka还有许多其他通信，比如
与请求群集成员身份的代理相关的事件。
与经纪人相关的事件。
正在获取引导配置设置。
与控制器和引线更新相关的事件。
帮助状态更新，如心跳更新。
zookeeper本身是一个分布式系统，由多个节点组成一个集合。zookeeper是维护这些元数据的集中服务。

在没有Zookeeper的情况下运行Kafka的要求似乎相当普遍。图书馆骗子解决了这个问题。
根据描述，江湖骗子或多或少是zookeeper的一个模仿者，提供由其他工具或数据库备份的zookeeper服务。
我在处理作者的主要产品时遇到了那个图书馆为骗子图书馆；好了，很好…

于2020年11月更新
对于最新版本（2.6.0），zookeeper仍然需要运行kafka，但在不久的将来，zookeeper将被一个自我管理的元数据仲裁所取代。
详见公认的kip-500。

1当前状态
kafka使用zookeeper存储关于分区和代理的元数据，并选择一个代理作为kafka控制器。
目前，消除对zookeeper的依赖正在进行中（通过kip-500）。
2搬迁利润
删除apache zookeeper依赖项提供了三个明显的好处：
首先，它通过整合kafka本身的元数据而不是在kafka和zookeeper之间拆分元数据来简化体系结构。这提高了稳定性，简化了软件，并使监视、管理和支持Kafka变得更容易。
其次，它提高了控制平面的性能，使集群能够扩展到数百万个分区。
最后，它允许kafka为整个系统建立一个单一的安全模型，而不是为kafka和zookeeper建立一个安全模型。
三。路线图
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     | None          |
| KIP-590 | Redirect Zookeeper Mutation Protocols to The Controller  |     Accepted     | None          |
| KIP-595 | A Raft Protocol for the Metadata Quorum                  |     Accepted     | None          |
| KIP-631 | The Quorum-based Kafka Controller                        | Under discussion | None          |

kip-500引入了桥梁版本的概念，它可以与kafka的kip-500前后版本共存。网桥版本很重要，因为它们可以实现对后zookeeper世界的零停机升级。
参考文献：
kip-500：用自我管理的元数据仲裁替换zookeeper
apachekafka不需要keeper：删除apachezookeper依赖关系
为kip-500准备客户端和工具：从apachekafka中删除zookeeper

首先
apachezookeeper是一个分布式存储，用于以高可用性的方式提供配置和同步服务。在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定期提交偏移量，以便在节点失败的情况下，它可以从以前提交的偏移量恢复（想象一下您自己处理所有这些）。
zookeeper在服务于许多其他目的方面也扮演着重要的角色，例如领导者检测、配置管理、同步、检测新节点何时加入或离开集群等。
未来的Kafka版本计划删除zookeeper依赖，但到目前为止，它是它的一个组成部分。
以下是他们常见问题页面中的几行：
一旦zookeeper仲裁关闭，代理可能会导致状态不好，无法正常服务客户端请求等。尽管当zookeeper仲裁恢复时，kafka代理应该能够自动恢复到正常状态，仍然有一些角落的情况下，他们不能和一个硬杀戮和恢复需要使它恢复正常。因此，建议您密切监视zookeeper集群并对其进行配置，以使其正常运行。
更多详情请点击此处