这是先前讨论的后续问题。我认为zookeeper是kafka代理或“消息总线”示例的协调器。我理解为什么我们可能希望生产者/消费者客户机通过zookeeper进行交易——因为zookeeper对于与哪个kafka代理进行交易具有内置的容错性。但是对于新的模型——即0.10.1+——我们是否应该在我们的生产者/消费者客户中完全绕过zookeeper？我们这样做是否会放弃任何优势（如更好的容错能力）？或者Zookeeper最终还在幕后工作？
这是先前讨论的后续问题。我认为zookeeper是kafka代理或“消息总线”示例的协调器。我理解为什么我们可能希望生产者/消费者客户机通过zookeeper进行交易——因为zookeeper对于与哪个kafka代理进行交易具有内置的容错性。但是对于新的模型——即0.10.1+——我们是否应该在我们的生产者/消费者客户中完全绕过zookeeper？我们这样做是否会放弃任何优势（如更好的容错能力）？或者Zookeeper最终还在幕后工作？
2条答案
按热度按时间xxe27gdn1#
zookeeper仍在幕后工作，但是0.9+客户机不需要再担心它，因为消费偏移量现在存储在kafka主题中，而不是存储在zookeeper中。
krugob8w2#
为了补充汉斯·杰斯珀森的回答，最近Kafka制作人/消费者客户（0.9+）不再与zookeeper互动。
现在zookeeper仅由kafka代理（即kafka的服务器端）使用。这意味着您可以锁定从客户端到所有zookeeper示例的外部访问，以提高安全性。
我理解为什么我们可能希望生产者/消费者客户机通过zookeeper进行交易——因为zookeeper对于与哪个kafka代理进行交易具有内置的容错性。
生产者/消费者客户不是通过zookeeper进行“交易”，见上文。
但是对于新的模型——即0.10.1+——我们是否应该在我们的生产者/消费者客户中完全绕过zookeeper？
如果你的问题的动机是因为你想实现你自己的Kafka生产者或消费者客户机，那么答案是：你的定制客户机不应该再出现了。kafka的官方生产者/消费者客户机（java/scala）或confluent的c/c++、python或go客户机演示了如何通过利用kafka功能（而不是必须依赖zookeeper等单独的服务）来实现可伸缩性、容错性等。
我们这样做是否会放弃任何优势（如更好的容错能力）？或者Zookeeper最终还在幕后工作？
不，我们不会放弃任何优势。否则，kafka项目就不会改变它的生产者/消费者客户机来停止使用zookeeper并开始使用kafka本身进行内部工作。
Zookeeper只是在Kafka经纪人的幕后工作，见上图。