Zookeeper対インメモリデータグリッド対Redis

Question

複数のリソースで異なる飼育係の定義を見つけました。多分それらのいくつかは文脈から外されていますが、それらを見てくださいpls：

私はRedisとHazelcastを使用してきましたが、Zookeeperをそれらと比較することで理解しやすくなります。

Zookeeperとメモリ内データグリッドおよびRedisを比較していただけますか？

分散メモリ計算の場合、zookeeperはメモリ内データグリッドとどのように異なりますか？
クラスタ間で同期する場合、他のすべてのメモリ内ストレージとどのように異なるのですか？同じin-memory-data-gridsは、クラスター全体のロックも提供します。 Redisにも何らかのトランザクションがあります。
それがメモリ内の一貫性のあるデータのみに関するものである場合は、他の選択肢があります。 Imdgを使用すると、同じことを実現できますね。

Robert Fraser · Accepted Answer

https://zookeeper.Apache.org/doc/current/zookeeperOver.html

デフォルトでは、Zookeeperはすべてのデータをすべてのノードに複製し、クライアントがデータの変更を監視できるようにします。変更は非常に迅速に（限られた時間内に）クライアントに送信されます。「エフェメラルノード」を作成することもできます。これは、クライアントが切断した場合、指定した時間内に削除されます。 ZooKeeperはreadsに対して高度に最適化されていますが、書き込みは非常に低速です（通常、書き込みが行われるとすぐにすべてのクライアントに送信されるため）。最後に、Zookeeperの「ファイル」（znode）の最大サイズは1MBですが、通常は単一の文字列になります。

まとめると、これはzookeeperが多くのデータを格納することを意図しておらず、キャッシュではないことを意味します。代わりに、ハートビートを管理したり、オンラインのサーバーを認識したり、構成を保存/更新したり、メッセージの受け渡しを行ったりするためです（ただし、メッセージ数が多い場合やスループットの要求が高い場合は、RabbitMQのようなものがこのタスクに適しています）。

基本的に、ZooKeeper（およびその上に構築されたキュレーター）は、クラスタリングのメカニズム（ハートビート、更新/構成の配布、分散ロックなど）の処理に役立ちます。

それは実際にはRedisに匹敵するものではありませんが、特定の質問については...

計算をサポートしておらず、ほとんどのデータセットで、パフォーマンスを維持してデータを保存することはできません。
クラスター内のすべてのノードに複製されます（データを分散できるRedisクラスターのようなものはありません）。すべてのメッセージは完全にアトミックに処理され、順序付けされるため、実際のトランザクションはありません。サービスにクラスター全体のロックを実装するのに使用でき（実際には非常に優れています）、どのノードがアクセスするかを制御するために、znode自体に多くのロックプリミティブがあります。
もちろん、ZooKeeperはニッチを埋めます。これは、大量のデータを格納/共有するためではなく、複数のインスタンスで分散アプリケーションをNiceに動作させるためのツールです。この目的で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に最適です。

Prateek Bansal · Answer

一貫性が保証ZooKeeperは、高性能でスケーラブルなサービスです。読み取りと書き込みはどちらも高速になるように設計されていますが、読み取りは書き込みよりも高速です。これは、読み取りの場合、ZooKeeperが古いデータを提供できるためです。これは、ZooKeeperの一貫性が保証されているためです。

クライアントからの順次整合性更新は、送信された順に適用されます。

原子性の更新は成功するか失敗するかのどちらかであり、部分的な結果はありません。

単一システムイメージクライアントは、接続先のサーバーに関係なく、サービスの同じビューを表示します。

信頼性更新が適用されると、それ以降、クライアントが更新を上書きするまで保持されます。この保証には2つの当然の結果があります。

クライアントが成功の戻りコードを取得した場合、更新は適用されています。一部の障害（通信エラー、タイムアウトなど）では、クライアントは更新が適用されたかどうかを認識しません。障害を最小限に抑えるための措置を講じていますが、唯一の保証は、成功した戻りコードが存在する場合のみです。（これはPaxosでは単調性条件と呼ばれます。）

読み取り要求または正常な更新によってクライアントに表示される更新は、サーバー障害からの回復時に決してロールバックされません。

適時性システムのクライアントビューは、特定の時間範囲内で最新であることが保証されています。（数十秒程度）。システムの変更は、この境界内のクライアントによって確認されるか、クライアントがサービスの停止を検出します。