ZookeeperまたはKafkaに保存されているオフセットは？
KafkaとZookeeperを使用すると、オフセットが保存される場所について少し混乱します。オフセットはZookeeperに保存される場合と、Kafkaに保存される場合があります。
オフセットがKafkaまたはZookeeperに格納されているかどうかを決定するものは何ですか？そして、長所と短所は何ですか？
NB：もちろん、オフセットを別のデータストアに自分で保存することもできますが、それはこの投稿の写真の一部ではありません。
私のセットアップに関するいくつかの詳細：
- これらのバージョンを実行します：KAFKA_VERSION = "0.10.1.0"、SCALA_VERSION = "2.11"
- NodeJSアプリケーションからkafka-nodeを使用してKafka/Zookeeperに接続します。
古いバージョンのKafka（pre 0.9）はZKのみにオフセットを格納しますが、新しいバージョンのKafkaは、デフォルトで内部にKafka= __consumer_offsetsというトピックにオフセットを格納します。新しいバージョンでもZKにコミットする可能性があります）。
オフセットをブローカーにコミットする利点は、コンシューマーがZKに依存しないため、クライアントがブローカーと通信するだけでよいため、アーキテクチャ全体が簡素化されることです。また、多くの消費者がいる大規模な展開では、ZKがボトルネックになる可能性がありますが、Kafkaはこの負荷を簡単に処理できます（オフセットのコミットはトピックへの書き込みとKafkaは非常によくスケーリングします-実際には、デフォルトで__consumer_offsetsは50パーティションで作成されます（IIRC）。
私はNodeJSやkafka-nodeに精通していません-オフセットのコミット方法はクライアントの実装に依存します。
簡単に言えば、ブローカー0.10.1.0を使用すると、トピック__consumer_offsetsにオフセットをコミットできます。ただし、このプロトコルを実装する場合は、クライアントに依存します。
より詳細には、古いクライアントは新しいブローカーと通信できるため、ブローカーとクライアントのバージョン（および使用しているコンシューマーAPI）に依存します。最初に、オフセットをKafka=トピックに書き込むことができるように、ブローカーとクライアントのバージョン0.9以上が必要です。しかし、古いクライアントが0.9ブローカーに接続している場合、オフセットをコミットしますZKへ。
Javaコンシューマ：
それは消費者が使用しているものに依存します：0.9より前には、2つの「古い消費者」、すなわち「高レベル消費者」と「低レベル消費者」があります。両方とも、オフセットを直接ZKにコミットします。 0.9以降、両方のコンシューマーは「新しいコンシューマー」と呼ばれる単一のコンシューマーにマージされました（基本的に、古いコンシューマーの低レベルAPIと高レベルAPIを統合します。つまり、0.9には3つのタイプのコンシューマーがあります）。新しいコンシューマーは、ブローカーにオフセットをコミットします（つまり、内部Kafkaトピック）
アップグレードを容易にするために、古いコンシューマを使用してオフセットを「二重コミット」する可能性もあります（0.9時点）。 dual.commit.enabledでこれを有効にすると、オフセットはZKと__consumer_offsetsトピックにコミットされます。これにより、オフセットをZKから__consumer_offsetsトピックに移動しながら、古いコンシューマーAPIから新しいコンシューマーAPIに切り替えることができます。
それはすべて、どのコンシューマを使用しているかによって異なります。 Kafka=バージョンに基づいて適切なコンシューマーを選択する必要があります。
バージョン0.8ブローカーはHighLevelConsumerを使用します。グループのオフセットは、zookeeperに保存されます。
ブローカーの場合0.9以上では、新しいConsumerGroupを使用する必要があります。オフセットはkafka=ブローカーで保存されます。
HighLevelConsumerは0.8以降のバージョンでも引き続き動作しますが、0.10.1そして、サポートはおそらくすぐになくなるでしょう。 ConsumerGroupには、使用をコミットした場合にHighLevelConsumerからの移行を支援するローリング移行オプションがあります。