なぜKafka消費者はzookeeperに接続し、プロデューサーはブローカーからメタデータを取得しますか？
消費者がzookeeperに接続してパーティションの場所を取得するのはなぜですか？そしてkafka=プロデューサーはメタデータを取得するためにブローカーの1つに接続する必要があります。
私のポイントは、すべてのブローカーがすでにメッセージを送信する場所をプロデューサーに伝えるために必要なすべてのメタデータを持っている場合、zookeeperの使用とは正確に何ですか？ブローカーはこれと同じ情報を消費者に送信できませんでしたか？
新しいメッセージが送信されるたびに動物園管理者に接続する必要がないように、ブローカーがメタデータを持っている理由を理解できます。 zookeeperに欠けている機能がありますか？ kafkaクラスター内でzookeeperが本当に必要な理由を考えるのは難しいと思っています。
まず第一に、zookeeperは高レベルの消費者にのみ必要です。 SimpleConsumerは、zookeeperの動作を必要としません。
高レベルのコンシューマーにzookeeperが必要な主な理由は、消費されたオフセットを追跡し、負荷分散を処理するためです。
より詳細に。
オフセットトラッキングに関して、次のシナリオを想像してください。コンシューマを開始し、100個のメッセージを消費し、コンシューマをシャットダウンします。次回コンシューマを起動するとき、おそらく最後に消費したオフセット（100）から再開する必要があります。つまり、最大消費オフセットをどこかに保存する必要があります。 zookeeperが起動する場所は次のとおりです。すべてのグループ/トピック/パーティションのオフセットを保存します。したがって、この方法で次に消費者を起動すると、「動物園の飼育係さん、消費を開始すべきオフセットは何ですか？」 Kafkaは、実際には、ズーキーパーだけでなく、他のストレージにもオフセットを保存できるようになっています（現時点では、zookeeperとkafkaのオフセットストレージのみが利用可能であり、kafkaストレージが完全に実装されているかどうかはわかりません）。
負荷分散については、生成されるメッセージの量は非常に多く、1台のマシンで処理できるため、おそらく何らかの時点で計算能力を追加する必要があります。 100個のパーティションを持つトピックがあり、この量のメッセージを処理するために10台のマシンがあるとします。ここで実際に発生するいくつかの質問があります。
- これら10台のマシンは、パーティションをどのように相互に分割する必要がありますか？
- マシンの1つが死んだらどうなりますか？
- 別のマシンを追加したい場合はどうなりますか？
繰り返しになりますが、zookeeperはここで開始します。グループ内のすべての消費者を追跡し、高レベルの各消費者がこのグループの変更をサブスクライブします。ポイントは、コンシューマーが表示または非表示になったときに、zookeeperがすべてのコンシューマーに通知し、リバランスをトリガーして、パーティションがほぼ均等に分割されるようにすることです（たとえば、負荷のバランスを取るため）。このようにして、消費者の1人が死んだ場合に、この消費者が所有していたパーティションの処理を続行します。
kafka 0.9+により、新しいConsumer APIが導入されました。グループコンシューマーはkafka自体によって提供されるため、Zookeeperへの接続は必要ありません。
kafka .9 release なので、消費者はZooKeeperに接続する必要はありません。APIを再設計し、新しい消費者クライアントが導入されました。
0.9リリースでは、新しく再設計されたコンシューマクライアントのベータサポートが導入されています。高レベルでは、新しいコンシューマーの主な違いは、「高レベル」ZooKeeperベースのコンシューマーと「低レベル」SimpleConsumer APIの区別を取り除き、代わりに統合コンシューマーAPIを提供することです。
そして
最後に、過去数年間に行われた一連のプロジェクトを完了して、KafkaクライアントをZookeeperから完全に分離し、ZooKeeperへのコンシューマークライアントの依存関係を完全に削除します。