Zookeeperはカフカの必須アイテムですか？

Kafkaでは、単一のブローカー、単一のトピック、および1つのプロデューサーと複数のコンシューマー（各コンシューマーがブローカーから独自のデータのコピーを取得する）を持つ単一のパーティションのみを使用したいと思います。これを考えると、Zookeeperを使用することによるオーバーヘッドは望みません。ブローカーだけを使用することはできませんか？飼育係はなぜしなければならないのですか？

はい、ZafkeeperはKafkaを実行するために必要です。Kafka Getting Startedドキュメントから：

ステップ2：サーバーを起動する

Kafkaはzookeeperを使用しているため、zookeeperサーバーがまだない場合は、まず開始する必要があります。kafkaにパッケージされている便利なスクリプトを使用して、ダーティな単一ノードzookeeperインスタンスを取得できます。

その理由については、分散システム全体でタスク、状態管理、構成などを調整する方法が必要であることを、かなり前からよく知っている人たちがいます。一部のプロジェクトは独自のメカニズムを構築しています（MongoDB分割クラスターの構成サーバー、またはElasticsearchクラスターのマスターノードを考えてください）。他の人たちは、Zookeeperを汎用の分散プロセス調整システムとして利用することを選択しました。したがって、Kafka、Storm、HBase、SolrCloudは、ほんの一部を挙げればすべて、Zookeeperを使用して管理と調整を支援します。

Kafkaは分散システムであり、Zookeeperを使用するように構築されています。Kafkaの分散機能を使用していないという事実によって、Kafkaの構築方法は変わりません。いずれにしても、Zookeeperの使用によるオーバーヘッドはそれほど大きくありません。より大きな問題は、なぜこの特定の設計パターンを使用するのかということです。Kafkaの単一のブローカー実装は、マルチブローカークラスターのすべての信頼性機能と、その拡張機能を利用できません。

他の人が説明したように、Kafka（最新バージョンでも）はZookeeperなしでは機能しません。

KafkaはZookeeperを次の目的で使用します。

コントローラーの選出。コントローラーはブローカーの1つであり、すべてのパーティションのリーダー/フォロワー関係を維持する責任があります。ノードがシャットダウンすると、他のレプリカにパーティションリーダーになって、ノードのパーティションリーダーを置き換えるように指示するのはコントローラーです。Zookeeperを使用してコントローラーを選択します。コントローラーが1つだけであることを確認し、クラッシュした場合は新しいコントローラーを選択します。

クラスターメンバーシップ -どのブローカーが有効で、クラスターの一部ですか？これもZooKeeperを通じて管理されます。

トピックの構成 -存在するトピック、各パーティションの数、レ​​プリカの場所、優先リーダー、各トピックに設定されている構成のオーバーライド

（0.9.0）-割り当て -各クライアントが読み書きできるデータの量

（0.9.0）-ACL-誰がどのトピック（古い高レベルのコンシューマー）に対して読み書きできるか-どのコンシューマーグループが存在し、誰がメンバーであり、各グループが各パーティションから取得した最新のオフセットはどれか。

[ https://www.quora.com/What-is-the-actual-role-of-ZooKeeper-in-Kafka/answer/Gwen-Shapiraから]

シナリオでは、1つのブローカーインスタンスと複数のコンシューマーを持つ1つのプロデューサーのみが、プッシャーを使用してチャネルを作成し、コンシューマーがそれらのイベントをサブスクライブして渡すことができるチャネルにイベントをプッシュできます。 https://pusher.com/

重要な更新-2019年8月：

ZooKeeperの依存関係はApache Kafkaから削除されます。KIP-500：ZooKeeperを自己管理メタデータクォーラムに置き換えるでの高レベルの議論を参照してください。

これらの取り組みには、いくつかのKafkaリリースと追加のKIPが必要です。Kafkaコントローラーは、現在のZooKeeperタスクのタスクを引き継ぎます。コントローラは、Kafkaのコアコンセプトであるイベントログの利点を活用します。

新しいKafkaアーキテクチャのいくつかの利点は、シンプルなアーキテクチャ、操作の容易さ、およびスケーラビリティの向上です（たとえば、「無制限のパーティション」を許可します）。

2020年7月に更新

最新バージョン（2.5.0）の場合、Kafkaを実行するにはZooKeeperが必要ですが、近い将来、ZooKeeperは自己管理メタデータクォーラムに置き換えられる予定です。

承認されたKIP-500の詳細を参照してください。

KafkaはZookeeperを使用するように構築されています。それからの脱出はありません。

Kafkaは分散システムであり、Zookeeperを使用してkafkaクラスターノードのステータスを追跡します。また、Kafkaトピック、パーティションなども追跡します。

あなたの質問を見ると、カフカは必要ないようです。Redis、Rabbit MQ などのpub-subをサポートするアプリケーション、またはPub-nubなどのホストされたソリューションを使用できます。

IMHO Zookeeperはオーバーヘッドではありませんが、あなたの生活をずっと簡単にします。

基本的には、クラスター内の異なるノード間の調整を維持するために使用されます。Kafkaの最も重要な点の1つは、zookeeperを使用して定期的にオフセットをコミットすることです。これにより、ノード障害が発生した場合に、以前にコミットされたオフセットから再開できます（自分でこれをすべて処理することを想像してください）。

Zookeeperは、リーダーの検出、構成管理、同期、新しいノードのクラスターへの参加またはクラスターからの離脱の検出など、他の多くの目的に役立つ重要な役割も果たします。

Kafkaの今後のリリースでは、飼育係の依存関係を削除する予定ですが、現時点ではそれが不可欠な部分です。

以下は、FAQページから抜粋した数行です。

Zookeeperクォーラムがダウンすると、ブローカーは状態が悪くなり、通常はクライアントのリクエストに対応できなくなります。Zookeeperクォーラムが回復すると、Kafkaブローカーは通常の状態に自動的に再開できるはずですが、まだいくつかのコーナーケースがあります彼らはそれを行うことができず、それを通常の状態に戻すにはハードキルアンドリカバリーが必要です。したがって、zookeeperクラスターを注意深く監視し、パフォーマンスが向上するようにプロビジョニングすることをお勧めします。

詳細はこちらをご確認ください

Zookeeperは、あらゆる種類の分散システムの集中管理システムです。分散システムは、さまざまなノード/クラスター（地理的に離れた場所にある可能性があります）で実行されるさまざまなソフトウェアモジュールですが、1つのシステムとして実行されます。Zookeeperは、ノード間の通信を容易にし、ノード間で構成を共有し、どのノードがリーダーであるか、どのノードが参加/脱退するかなどを追跡します。Zookeeperは、分散システムを正常に保ち、一貫性を維持するものです。Zookeeperは基本的にオーケストレーションプラットフォームです。

Kafkaは分散システムです。ひいてはそれがオーケストレーションのいくつかの種類を必要とする地理的に離れた（またはしない）かもしれないそのノードについて。

はい、ZookeeperはKafkaの仕様によるものです。Zookeeperは、一種のKafkaクラスターを管理する責任があるためです。それには、すべてのKafkaブローカーのリストがあります。ブローカーがダウンしたり、パーティションがダウンしたり、新しいブローカーが起動したり、パーティションが起動したりすると、Kafkaに通知します。つまり、ZKはすべてのKafkaブローカーをKafkaクラスターの現在の状態について最新の状態に保ちます。

次に、すべてのKafkaクライアント（プロデューサー/コンシューマー）は、単一のブローカーに接続するだけで、そのブローカーはすべてのメタデータをZookeeperによって更新されるため、クライアントはブローカーの発見の頭痛を気にする必要がありません。

通常のペイロードメッセージ転送以外にも、kafkaでは次のような多くの通信が行われます。

• クラスターメンバーシップを要求するブローカーに関連するイベント。
• ブローカーに関連するイベントが利用可能になります。
• ブートストラップ構成のセットアップを取得しています。
• コントローラーとリーダーの更新に関連するイベント。
• ハートビート更新などのステータス更新を支援します。

Zookeeper自体は、アンサンブル内の複数のノードで構成される分散システムです。Zookeeperは、このようなメタデータを維持するための集中サービスです。

この記事では、KafkaにおけるZookeeperの役割について説明します。カフカがステートレスである方法と、ゾケッパーがカフカの分散された性質（およびより多くの分散システム）で重要な役割を果たす方法を説明します。

ZookeeperなしでKafkaを実行する要求は、ごく一般的なようです。ライブラリCharlatanはこれに対処します。

説明によると、CharlatanはほぼZookeeperのモックであり、他のツールまたはデータベースによってバックアップされたZookeeperサービスを提供しています。

Charlatanライブラリの作者の主な製品を扱っているときに、そのライブラリに遭遇しました。そこでうまくいきます…

第一に

Apache ZooKeeperは、高可用性の方法で構成および同期サービスを提供するために使用される分散ストアです。カフカの最近のバージョンでは、仕事はそれがZooKeeperのにメッセージ（オフセットと呼ばれる）を消費していたどれだけについてではない店舗情報へのクライアント消費者のために行われた.This reduced usage did not get rid of the need for consensus and coordination in distributed systems however.カフカを提供していますが、フォールトトレランスと回復力を、何かを提供するために必要とされています調整が必要であり、ZooKeeperはシステム全体の一部を有効にします。

第二に

パーティションのリーダーが誰であるかについて合意することは、Kafkaエコシステム内でのZooKeeperの実用的なアプリケーションの一例です。

Zookeeper would work if there was even a single broker. 

これらはKafka In Actionの本からです。画像はこのコースからのものです