当使用Kafka和Zookeeper时，我对存储偏移量的位置感到困惑。在一些情况下，偏移似乎存储在Zookeeper中，在其他情况下，它们存储在Kafka中。保存在Zookeeper或Kafka中的偏移量？
什么决定偏移量是存储在卡夫卡还是存储在Zookeeper中？什么是利弊？
注：当然，我也可以在一些不同的数据存储中存储偏移量，但这不是本文的图片的一部分。
关于我的设置更多的细节：
卡夫卡的旧版本（预0.9）店偏移量ZK而已，而内部卡夫卡主题卡夫卡的新版本，默认情况下店偏移称为__consumer_offsets（较新的版本可能仍然致力于尽管ZK）。
向代理商提交补偿的好处是，消费者不依赖于ZK，因此客户只需要与简化整体架构的代理交谈即可。此外，对于有很多消费者的大型部署，ZK可能会成为瓶颈，而Kafka可以轻松处理这种负载（承诺补偿与撰写主题相同，Kafka在这里可以很好地扩展 - 事实上，默认情况下，__consumer_offsets是用50个分区IIRC创建）。
我不熟悉NodeJS或kafka节点 - 它取决于客户端实现如何提交偏移量。
长话短说：如果您使用经纪人0.10.1.0您可以对主题__consumer_offsets提交补偿。但它取决于你的客户端，如果它实现了这个协议。
更详细地说，它取决于您的经纪人和客户端版本（以及您使用的是哪种消费者API），因为较早的客户端可以与较新的经纪人交谈。首先，您需要拥有经纪人和客户端版本0.9或更高版本才能将偏移量写入卡夫卡主题。但是，如果较早的客户端连接到0.9代理，它仍会将偏移量提交给ZK。
对于Java消费者：
这取决于什么消费者使用：0.9前有两个“老客户”，即“高级用户”和“低层次的消费”。两者都直接向ZK提交补偿。自0.9以来，两个消费者都被合并为单一消费者，称为“新消费者”（它基本上统一了两个老消费者的低水平和高水平的API--这意味着，在0.9中有三种类型的消费者）。新消费者承诺抵消经纪人（即内部卡夫卡主题）
为了使升级更容易，还可以使用旧消费者“双重提交”补偿（截止到0.9）。如果您通过dual.commit.enabled启用此功能，则会将偏移量提交给ZK和__consumer_offsets主题。这允许您从旧消费者API切换到新的消费者API，同时将您从ZK的偏移移动到__consumer_offsets主题。
这一切取决于您使用的是哪一位消费者。您应该根据您的Kafka版本选择合适的消费者。
版本0.8经纪人使用HighLevelConsumer。您的组的偏移量存储在zookeeper中。
对于经纪人0.9及更高版本，您应该使用新的ConsumerGroup。补偿与卡夫卡经纪人一起存储。
请注意，HighLevelConsumer仍然可以在0.8版本以上使用，但它们已在0.10.1中弃用，支持很快就会消失。如果您承诺使用它，ConsumerGroup具有滚动迁移选项以帮助从HighLevelConsumer迁移。
Thx，我会确保升级到最新的API。 –