ある種の固有の構成管理の問題があります。zookeperがそれを解決するために作られているとは思いませんが、間違っている可能性があります。
システムは、ネットワーク内の複数のデバイスに構成をプロビジョニングします。構成自体は、数千万の構成オブジェクトで構成されています。
デバイスがまだプロビジョニングされていない場合は、構成全体の現在のバージョン（数千万のオブジェクト）を読み取る必要があります。
デバイスがプロビジョニングされたら、構成に対するバージョン管理された変更を受け取る必要があります。変更は、数百/秒、または数千/秒のオーダーでのみ発生します。
動物園の飼育係のドキュメントベースのモデルと1MBの応答制限があるため、これには適切ではないようです。私が間違っている？
ZooKeeper はまだアプリケーションに適していない可能性がありますが、操作ごとに 1 MB の応答制限があります。したがって、すべての構成オブジェクトのサイズが 1 MB 未満であれば、それらの読み取り/書き込みに問題はありません。
このシナリオでは、留意すべき点がいくつかあります。すべてのデータはメモリに保存されます。ディスクにログを記録することで耐久性が向上し、レプリケーションを使用して信頼性が高まりますが、メモリが不足すると終わりです。znode ごとのメモリ オーバーヘッドもあります (100 バイト程度)。10,000,000 個のオブジェクトがあり、各オブジェクトが 100 バイトしか格納しない場合、メモリ フットプリントは 2G 程度になります。サーバーが比較的適切にプロビジョニングされていると仮定すると、これはそれほど問題にはなりません。また、起動時に 2G 単位のデータを読み込む必要があるため、クラッシュからの回復には時間がかかることに注意してください。
クライアント側にも関連する問題があります。クライアントが実際にすべての構成オブジェクトを読み取ろうとすると、ネットワークを介して大量のデータをプルすることになります! 各オブジェクトが 1 MB 未満であると仮定すると、制限に達することはありませんが、少し時間がかかります。