ZookeeperはKafkaの必須アイテムですか？
Kafkaでは、単一のブローカー、単一のトピック、および1つのプロデューサーと複数のコンシューマー（各コンシューマーがブローカーから独自のデータのコピーを取得する）を持つ単一のパーティションのみを使用したいと思います。これを考えると、Zookeeperを使用するオーバーヘッドは必要ありません。ブローカーのみを使用することはできませんか？ Zookeeperが必要なのはなぜですか？
はい、Kafkaを実行するにはZookeeperが必要です。 Kafka入門ドキュメントから：
ステップ2：サーバーを起動する
Kafkaはzookeeperを使用するため、zookeeperサーバーをまだ持っていない場合は、最初に起動する必要があります。 kafkaにパッケージ化された便利なスクリプトを使用して、簡単で汚い単一ノードのzookeeperインスタンスを取得できます。
理由については、かなり前に、分散システム全体でタスク、状態管理、構成などを調整する何らかの方法が必要であることを人々は発見しました。一部のプロジェクトは独自のメカニズムを構築しています（MongoDBシャードクラスターの構成サーバー、またはElasticsearchクラスターのマスターノードを考えてください）。他の人は、Zookeeperを汎用分散プロセス調整システムとして利用することを選択しました。そのため、Kafka、Storm、HBase、SollCloudは、Zookeeperを使用して管理と調整を支援しています。
Kafkaは分散システムであり、Zookeeperを使用するように構築されています。 Kafkaの分散機能を使用していないという事実は、その構築方法を変更しません。いずれにしても、Zookeeperの使用によるオーバーヘッドはそれほど大きくありません。大きな問題は、この特定の設計パターンを使用する理由です。Kafkaの単一のブローカー実装では、マルチブローカークラスターのすべての信頼性機能とその拡張機能を逃してしまいます。
他の人が説明したように、Kafka（最新バージョンでも）はZookeeperなしでは機能しません。
Kafkaは次の目的でZookeeperを使用します。
コントローラーの選択。コントローラーはブローカーの1つであり、すべてのパーティションのリーダー/フォロワー関係を維持する責任があります。ノードがシャットダウンすると、コントローラーが他のレプリカにパーティションリーダーになるように指示し、ノード上のパーティションリーダーを置き換えます。 Zookeeperは、コントローラーを選択するために使用されます。コントローラーが1つしかないことを確認し、クラッシュした場合は新しいコントローラーを選択します。
クラスターメンバーシップ-どのブローカーが生きており、クラスターの一部ですか？これもZooKeeperで管理されます。
トピック構成-存在するトピック、各パーティションの数、レプリカの場所、優先リーダー、各トピックに設定されたオーバーライドの設定
（0.9.0）-クォータ-各クライアントが読み書きできるデータ量
（0.9.0）-ACLs-誰がどのトピック（古い高レベルの消費者）に読み書きできるか-存在する消費者グループ、誰メンバーと各グループが各パーティションから取得した最新のオフセットは何ですか。
[from https://www.quora.com/What-is-the-actual-role-of-ZooKeeper-in-Kafka/answer/Gwen-Shapira ]
シナリオに関しては、1つのブローカーインスタンスと1つのプロデューサーのみが複数のコンシューマーであり、プッシャーを使用してチャネルを作成し、コンシューマーがそれらのイベントをサブスクライブして渡すことができるチャネルにイベントをプッシュできます。 https://pusher.com/
IMHO Zookeeperはオーバーヘッドではありませんが、あなたの人生をずっと楽にします。
基本的には、クラスター内の異なるノード間の調整を維持するために使用されます。 Kafkaで最も重要なことの1つは、ノード障害が発生した場合に以前にコミットされたオフセットから再開できるように、定期的にオフセットをコミットするためにzookeeperを使用することです.
Zookeeperは、リーダーの検出、構成管理、同期、新しいノードがクラスターに参加または離脱したときの検出など、他の多くの目的に役立つ重要な役割も果たします。
将来のKafkaリリースでは、zookeeperの依存関係を削除することを計画していますが、現時点ではそれは不可欠な部分です。
FAQページから抜粋した数行を次に示します。
Zookeeperクォーラムがダウンすると、ブローカーは悪い状態になる可能性があり、通常はクライアント要求などを処理できません。Zookeeperクォーラムが回復すると、Kafkaブローカーは自動的に通常の状態に再開できるはずですまだできない少数のコーナーケースであり、通常の状態に戻すにはハードキルとリカバリが必要です。したがって、zookeeperクラスターを厳密に監視し、パフォーマンスが向上するようにプロビジョニングすることをお勧めします。
詳細については here を確認してください
重要な更新-2019年8月：
ZooKeeper依存関係は、Apache Kafkaから削除されます。 KIP-500：ZooKeeperを自己管理メタデータクォーラムに置き換える の高レベルの説明を参照してください。
これらの努力には、いくつかのKafkaリリースと追加のKIPが必要です。 Kafkaコントローラーは、現在のZooKeeperタスクのタスクを引き継ぎます。コントローラーは、Kafkaのコアコンセプトであるイベントログの利点を活用します。
新しいKafkaアーキテクチャのいくつかの利点は、アーキテクチャの単純化、操作の容易さ、およびスケーラビリティの向上です（たとえば、「無制限のパーティション」を許可します）。
通常のペイロードメッセージ転送以外にも、kafkaで行われる他の多くの通信があります。のような*クラスターメンバーシップを要求するブローカーに関連するイベント*ブローカーに関連するイベントが利用可能になる* bootstrap構成設定の取得。 *コントローラーとリーダーの更新に関連するイベント。 *ハートビートアップデートなどのステータスアップデートを支援します。
Zookeeper自体は、アンサンブル内の複数のノードで構成される分散システムです。 Zookeeperは、このようなメタデータを維持するための集中サービスです。
Zookeeperは、あらゆる種類の分散システムの集中管理システムです。分散システムは、異なるノード/クラスターで実行される（地理的に離れた場所にある場合があります）が、1つのシステムとして実行される異なるソフトウェアモジュールです。 Zookeeperは、ノード間の通信を容易にし、ノード間で構成を共有し、どのノードがリーダーであるか、どのノードが参加/離脱するかなどを追跡します。 Zookeeperは基本的にオーケストレーションプラットフォームです。
Kafkaはdistributedシステムです。したがって、それは何らかのオーケストレーションが必要地理的に離れている（またはそうでない）ノードの場合です。