https://zookeeper.apache.org/doc/current/zookeeperOver.html
デフォルトでは、Zookeeperはすべてのデータをすべてのノードに複製し、クライアントがデータの変更を監視できるようにします。変更は非常に迅速に（制限された時間内に）クライアントに送信されます。また、クライアントが切断された場合に指定された時間内に削除される「エフェメラルノード」を作成することもできます。 ZooKeeperは、読み取り用に高度に最適化されています 、書き込みは非常に遅いですが（通常、書き込みが行われるとすぐにすべてのクライアントに送信されるため）。最後に、Zookeeperの「ファイル」（znode）の最大サイズは1MBですが、通常は単一の文字列になります。
まとめると、これは、zookeeperが多くのデータを保存することを意図しておらず、キャッシュではないことを意味します。代わりに、ハートビートの管理/オンラインのサーバーの確認、構成の保存/更新、場合によってはメッセージパッシングを行うためのものです（ただし、メッセージの数が多い場合やスループットの要求が高い場合は、RabbitMQのようなものがこのタスクにはるかに適しています）。
基本的に、ZooKeeper（およびそれに基づいて構築されたCurator）は、クラスタリングのメカニズム（ハートビート、更新/構成の配布、分散ロックなど）の処理に役立ちます。
これは実際にはRedisに匹敵するものではありませんが、特定の質問については...
-
計算をサポートしておらず、ほとんどのデータセットでは、パフォーマンスの高いデータを保存できません。
-
クラスター内のすべてのノードに複製されます（データを分散できるRedisクラスタリングのようなものはありません）。すべてのメッセージは完全にアトミックに処理され、シーケンスされるため、実際のトランザクションはありません。サービスにクラスター全体のロックを実装するために使用できます（実際には非常に優れています）。また、znode自体に多くのロックプリミティブがあり、どのノードがそれらにアクセスするかを制御します。
-
もちろんですが、ZooKeeperはニッチを埋めます。これは、大量のデータを保存/共有するためではなく、分散アプリケーションを複数のインスタンスでうまく機能させるためのツールです。この目的でIMDGを使用する場合と比較して、Zookeeperは高速で、ハートビートと同期を予測可能な方法で管理し（この部分を簡単にするための多くのAPIを使用）、ノードが「プル」ではなく「プッシュ」パラダイムを備えています。変更がすぐに通知されます。
リンクされた質問からの引用...
Zookeeperの使用法の標準的な例は、分散メモリの計算です
...は、IMO、少し誤解を招くものです。データを提供するのではなく、計算を調整するために使用します。たとえば、テーブルの行1〜100を処理する必要があるとします。 「1-10」、「11-20」、「21-30」などの名前で10個のZKノードを配置できます。クライアントアプリケーションはZKによってこの変更を自動的に通知され、最初のノードは「 1-10"およびエフェメラルノードを設定しますclients/192.168.77.66/processing/rows_1_10
次のアプリケーションはこれを確認し、次のグループで処理します。計算する実際のデータは他の場所（つまり、Redis、SQLデータベースなど）に保存されます。ノードが計算の途中で失敗した場合、別のノードがこれを確認し（30〜60秒後）、ジョブを再度取得する可能性があります。
ただし、ZooKeeperの標準的な例はリーダー選出だと思います。 3つのノードがあるとしましょう。1つはマスターで、他の2つはスレーブです。マスターがダウンした場合、スレーブノードが新しいリーダーになる必要があります。このタイプのものはZKに最適です。