0

CuratorFramework で Zookeeper に基づくアプリケーションを作成しようとしています。アプリケーションは、より多くのノードでクォーラムで実行できる必要があります。アプリのすべてのインスタンスには、Zookeeper サーバーとクライアントのインスタンスが埋め込まれています。ノードはクォーラムに正常にアセンブルされます。各ノードは EPHEMERAL ノードを /workers/active/node1 に書き込みます (「アクティブ」はリーダーによって作成された PERSISTENT znode です)。Zookeeper は非常にゆっくりとノードの障害を検出し、クライアントが Zookeeper サーバーの localhost インスタンスに接続されたときにセッションの有効期限が切れた後にエフェメラル ノードが消失したため、接続文字列 "NodeB, NodeC" を使用して NodeA のクライアントをクラスターに接続することにしました。接続文字列 "NodeA, Node C" を持つ NodeB と "NodeA, NodeB" を持つ NodeC。これにより、クラスターはノード障害の検出がはるかに高速になります。/workers/active で NodeChildren イベントを検出するために、各ノードにウォッチャーを追加しました。このウォッチャーには、localhost Zookeeper サーバーに接続された CuratorFramework クライアントの特別なインスタンスがあります。コールバックはクライアントが登録したサーバーにのみ登録されるため、このようにしました。問題は、その解決策が安定しておらず、その理由がわからないことです。すべてが正しく機能することもありますが、その後、/workers/active の znode が失われますが、すべてのノードが実行されているか、/workers/active の状態は正しいのですが、NodeChildren コールバックは、数秒前に正しく機能していたとしても機能しません。 ..何が間違っているのでしょうか? 私はすべてを試しました... コールバックは、クライアントが登録したサーバーにのみ登録されるためです。問題は、その解決策が安定しておらず、その理由がわからないことです。すべてが正しく機能することもありますが、その後、/workers/active の znode が失われますが、すべてのノードが実行されているか、/workers/active の状態は正しいのですが、NodeChildren コールバックは、数秒前に正しく機能していたとしても機能しません。 ..何が間違っているのでしょうか? 私はすべてを試しました... コールバックは、クライアントが登録したサーバーにのみ登録されるためです。問題は、その解決策が安定しておらず、その理由がわからないことです。すべてが正しく機能することもありますが、その後、/workers/active の znode が失われますが、すべてのノードが実行されているか、/workers/active の状態は正しいのですが、NodeChildren コールバックは、数秒前に正しく機能していたとしても機能しません。 ..何が間違っているのでしょうか? 私はすべてを試しました...

4

1 に答える 1

0

解決策を見つけました。

私の場合、ノード登録に CuratorFramework レシピのPersistentEphemeralノードを使用するのが最適なオプションです。

追加/削除されたノードを検出するコールバックには、CuratorFramework レシピのPathChildrenCacheを使用し、コールバックを前置するのが最適です。

于 2015-08-10T18:56:29.930 に答える