私は、KafkaとZookeeperを使用しているときにオフセットが格納されている場所について少し混乱しています。いくつかのケースではオフセットは動物園で保存されているように見えますが、他のケースではカフカに保存されています。ZookeeperまたはKafkaにオフセットが保存されていますか？
オフセットがカフカに保存されているのかZookeeperに保存されているのかを決めるには？賛否両論は何ですか？
NB：もちろん、別のデータストアに自分でオフセットを保存することもできますが、これはこの投稿の画像の一部ではありません。
私のセットアップに関するいくつかの詳細：
古いバージョンZKに店舗オフセット（0.9をプリ）のみ、カフカの新しいバージョンながら、__consumer_offsetsと呼ばれる内部カフカのトピックのデフォルトのストア・オフセットによって（新しいバージョンはまだかかわらず、ZKするコミットかもしれません）。
ブローカへのオフセットをコミットする利点は、消費者がZKに依存しないことで、クライアントはブローカと話すだけで全体的なアーキテクチャを簡素化できることです。また、多くの消費者がいる大規模な展開では、Zafがボトルネックになることがありますが、Kafkaはこの負荷を簡単に処理できます（オフセットのコミットは、トピックへの書き込みとカフカのスケールと同じです - 実際デフォルトでは__consumer_offsetsです）。 50パーティションIIRCで作成）。
私はNodeJSまたはkafka-nodeに慣れていません。オフセットのコミット方法に依存します。
ブローカー0.10.1.0を使用すると、トピック__consumer_offsetsへのオフセットをコミットできます。しかし、このプロトコルを実装している場合は、クライアントに依存します。
より詳細には、古いクライアントは新しいブローカーと話すことができるため、ブローカーとクライアントのバージョン（および使用しているコンシューマーAPI）によって異なります。まず、Kafkaトピックにオフセットを書き込むには、ブローカーとクライアントのバージョン0.9以上が必要です。しかし、古いクライアントが0.9ブローカに接続している場合でも、ZKへのオフセットをコミットします。 Javaの消費者のために
：
それは使用している消費者によって異なります。0.9の前にある二つの「古い消費者」すなわち「ハイレベルの消費者」と「低レベルの消費者」。両方とも、ZKに直接オフセットをコミットします。 0.9以降、両方のコンシューマーが「新しいコンシューマー」と呼ばれる単一のコンシューマーに統合されました（これは古いコンシューマーの両方の低レベルおよび高レベルAPIを基本的に統一します）。
アップグレードを容易にするために、旧コンシューマ（0.9のように）を使用して「二重コミット」オフセットを適用する可能性もあります。新しい消費者は、ブローカー（つまり、カフカの内部トピック） dual.commit.enabledでこれを有効にすると、オフセットはZKと__consumer_offsetsのトピックにコミットされます。これにより、ZKから__consumer_offsetsトピックにオフセットを移動しながら、古いコンシューマAPIから新しいコンシューマAPIに切り替えることができます。
すべての消費者によって異なります。 Kafkaバージョンに基づいて適切な消費者を選択する必要があります。
バージョン0.8ブローカーはHighLevelConsumerを使用します。あなたのグループのオフセットは、動物園に保存されます。
ブローカー0.9以降では、新しいConsumerGroupを使用する必要があります。オフセットはカフカブローカで保存されます。
HighLevelConsumerは0.8より古いバージョンでも機能しますが、0.10.1で廃止され、サポートはすぐに終了します。 ConsumerGroupには、使用を約束した場合はHighLevelConsumerからの移行を支援するローリング移行オプションがあります。
Thx、私は最新のAPIにアップグレードしてください。 –