問題タブ [apache-curator]

このリンク、Official Zookeeper docでは、引用があいまいです。

ZooKeeper はそのデータをデータ ディレクトリに格納し、そのトランザクション ログをトランザクション ログ ディレクトリに格納します。デフォルトでは、これら 2 つのディレクトリは同じです。サーバーは、トランザクション ログ ファイルをデータ ファイルとは別のディレクトリに格納するように構成できます (構成する必要があります)。トランザクション ログが専用のログ デバイスに存在する場合、スループットが向上し、待ち時間が短縮されます。

トランザクション ログ ファイルは、トランザクション ログを別のディレクトリに保存する必要があると書かれています。では、専用のデバイスが最適であると言うのですか? デフォルトで、データ ディレクトリ ファイルとトランザクション ログ ファイルを同じ場所に保存するのはなぜですか? 「ディレクトリ」の意味を理解していない可能性があるため、混乱していると思います。ディレクトリと聞くとフォルダを思い浮かべます。ディレクトリと言うとき、ハードウェア ストレージ デバイスを意味しますか? これらのファイルが同じデバイスに保存されていても、異なるフォルダーに保存されている場合、スループットが向上し、遅延が減少するとは思えません。ファイルが別のデバイスに保存されている場合、スループットが向上し、遅延が減少すると予想されます。

ドキュメントを正しく解釈していますか? トランザクション ログとデータ ファイルを別のフォルダーに格納するだけでは、パフォーマンスは向上しません。それらは、それらが異なるハードウェアストレージデバイスに保存されている場合に、これらの利益が得られることを意味するだけですか?

Java アプリケーションから追加する場合znode、Exhibitors Explorer はノードのステータスを表示できません。私が得たエラーは次のとおりKeeperErrorCode = NoAuth for /z/node/pathです。一方、REST API ( PUT www.my-zookeeper.com//exhibitor/v1/explorer/znode/z/node/path) から znode を追加すると、すべてが正しく機能します。

私の意見では、Java クライアントがDigestLoginModule認証を使用しているため、問題が発生している可能性があります。

また、Exhibitor でノードを分析しようとすると、次のエラーが発生します。

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 コールバックは、数秒前に正しく機能していたとしても機能しません。 ..何が間違っているのでしょうか? 私はすべてを試しました...

Zookeeper と Curator は初めてです。

Curator または Zookeeper で、Zookeeper 接続の接続プールを維持できる方法があるかどうかを知りたいです。

Webで調べてみたのですが、CuratorFramework/Zookeeperは1つあれば十分という意見や、複数の接続を並行して使うには何度も接続を試みるという意見がほとんどでした。

私が設計しているシステムには、高い番号が必要です。Zookeeper からの並列読み取り/秒。単一の飼育係接続で Curator を使用しています。複数の Zookeeper 接続により、読み取りを順次ではなく並列に行うことができます。また、新しい接続を何度も開始することによる遅延を減らしたいと考えています。

理想的には、接続プールが存在するはずですが、そうでない場合は自分でそれを行う必要があるかもしれません。

誰かがすでに存在するものを指摘できますか?

データベースのペシミスティック ロックを Curator プロセス間ロックに置き換えようとしています。データベース ロックでselect for updateは、トランザクションの開始時にエンティティをロックし、トランザクションがコミットされると解放されます。トランザクションは複数のメソッドにまたがる可能性があり、チェーン内のいずれかのメソッドがこのロックを再度取得しようとすると、同じトランザクション/スレッドで実行されているため取得されます。

Zookeeper ロックを使用すると、私が見た例は次のようになります。

サービス呼び出しが複数のメソッドにまたがり、それらのメソッドのいずれかが個別にこのロックを取得しようとすると、これは問題を引き起こします。これらは独立したビジネスメソッドであるため、ロックが渡されることは望ましくありません。同じスレッドで実行している場合、この同じロック オブジェクトを返すサービス/ファクトリの実装はありますか?

コードが示すように、ビジネス コードで例外をキャッチしたので、Zookeeper が切断されても、ビジネス コードは引き続き実行されます。