問題タブ [apache-curator]

znodes address,sessiontimeoutinms,connectiontimeoutinms,Retry) を取る CuratorFrameworkFactory.newClient メソッドの助けを借りて Empheral ノードを作成しています。sessiontimeoutinms として 5*1000 を渡し、connectiontimeoutinms として 15*1000 を渡しました。この方法で飼育係に EPHEMERAL ノードを作成できますが、この EPHEMERAL ノードはアプリケーションが実行されるまで削除されません。

sessiontimeout が 5 秒であるため、これが発生する理由。

InterProcessSemaphoreMutex キュレーター レシピを使用して、アプリケーション プロセスが常にシングルトンであることを確認しています。一時的なネットワーク エラーやアプリケーションの一時停止 (GC などによる) が原因で、ミューテックスが失われることがあります。プロセスがロックの再取得を試行できるように、再試行ポリシーを使用しています。(たとえば) 5 分以内にロックを再取得できない場合、アプリケーション プロセスを終了させたいと考えています。

レシピのドキュメントでは、ConnectStateChange イベントをリッスンできることが示唆されています。Zookeeper への接続が失われたことを示すイベント LOST が失われたため、プロセスもロックを失いました。このようにして、プロセスはロックを失ったかどうかを検出できます。

プロセスがロックの再取得に成功したかどうかを確認するにはどうすればよいですか? この情報を提供できるミューテックスのメソッドが見つかりません。疑わしいほど有用な「isAcquiredInThisProcess」メソッドは、実際にはその情報を提供しません。

私はキュレーターと zk に不慣れで、コミュニティの他のメンバーと私の理解を再確認したいと考えていました。キュレーターのドキュメントはあまりカバーされていないようです。

キュレーターの永続的なエフェメラル ノードは、基本的にエフェメラル znode ですが、切断されたときに接続を再確立するための追加のメカニズムがありますか? 明らかではない他の違いはありますか？

ps zk (またはさらに良いことに、キュレーター) のコミュニティ/ディスカッション グループはありますか? 簡単なグーグル検索では何も見つかりませんでした。

次の動作が確認されていますが、これが既知のバグなのか、単にライブラリの構成ミスまたは誤用なのかはわかりません。

• curator-framework 2.7.0 Scala ライブラリ、zookeeper-3.4.5 を使用
• 127.0.0.1:2181 でローカル zk サーバーに接続する scala アプリを実行します。さまざまな再試行ポリシーでこれを再現しましたが、簡単にするために、再試行ポリシーが 30 秒間スリープし、無期限に再試行すると仮定しましょう。
• scala アプリ ログとローカル zk サーバー ログの両方を追跡します。
• 「sudo iptables -A OUTPUT -p tcp --dport 2181 -j DROP」を実行して待ちます。
• 最終的に、SUSPENDED 状態変更ログが scala アプリ ログに表示されるのを確認します。
• 最終的に、「セッションの有効期限」ログが zk サーバー ログに表示されます。今 iptables を持ち上げると、scala アプリは LOST に続いて RECONNECTED を登録します。これが私たちの期待です。
• サーバーが SessionExpiration をログに記録した直後に iptables を持ち上げるのではなく、待機を続けると、ログに retryPolicy イベントが発生して失敗することがわかります。私が知る限り、まだ期待されています。
• 問題は、「長い時間」後に iptables を持ち上げてから、何度か再試行した場合です。ここで発生しているように見えるのは、新しいセッション ID を使用した RECONNECTED であり、LOST 状態の変更はありません。最終的な結果として、接続はされていますが、すべての一時データが失われ、このロジックが LOST 状態の変更に関連付けられているため、再構築を試みません。

これは、クライアント セッション ID の「タイムアウト」または「クリア」と関係があるようで、サーバーの再接続では、クライアントがセッションの期限切れを既に認識していると見なされます。これに関する確認はありますか？私たちの現在の考えでは、前後にセッション ID をキャッシュし、独自の LOST 状態の変化をシミュレートすることですが、これは API と戦っているように思えます。

ありがとう

chroot されたパスと名前空間はApache Curatorで同じことを意味しますか?

たとえば、curator を で作成するとmyserver:2181/pathA、名前空間が に設定されるということpathAですか?

または、名前空間が に設定されている場合pathA、それは zk パスを に設定することと同じmyserver:2181/pathAですか?

2 つの一般的な使用法を比較できる人がいれば、それは役に立ちます。

私はApache ZooKeeper (「ZK」) が解決する問題の種類を正確に理解しようとしています。おそらく、ZK のレシピ ページから始めるのが最適です。

まず、次の仮定を立てています。

• ZooKeeper API (Java と C の両方で利用可能) は、これらの 7 つの単純なメソッドを公開し、「ZK レシピ」として知られる独自の使用パターンを構築できるようにします。
• これらの ZK レシピを使用して、分散プログラミングの問題を自分で解決するのはあなた次第です。
• または、独自の ZK レシピを作成する代わりに、 Apache Curatorに同梱されているレシピを使用することもできます。
• いずれにせよ、分散コンピューティングの問題を解決するために ZK Recipes (ここでも自家製または Curator によって提供されます) を使用しています。

私は、 Apache Kafkaがこの例であると考えています。Kafka は ZK を使用して分散キュー(リストされている ZK レシピの 1 つ) を作成します。したがって、私の仮定が正しければ、ZK はこれらの API メソッドを公開し、Apache Kafka の作成者は ZK を直接使用するか、Curator を使用して「キュー」ZK レシピを実装しました。

上記の仮定のいずれかが間違っている場合は、まず修正してください。私が多かれ少なかれ順調に進んでいると仮定します：

ZK レシピのリストを見ると、次のように表示されます (すべてを網羅しているわけではありません)。

• 障壁
• ロック
• リーダー選挙

これらのレシピとそれらが提示する解決策を理解するためには、まずそれらが解決する問題を理解する必要があります! 基本的なJavaの同時実行性からロックが何であるかは理解していますが、「分散ロック」が必要になる場合のユースケースを見ていません。選挙をリードするために、最初にそれを必要とするユースケースとして私が考えることができるのは、組み込みのマスター/スレーブまたはプライマリ/セカンダリ機能を搭載して出荷したいアプリケーションを構築している場合だけです。おそらくその場合、ZK を使用して独自の「リーダー選出」レシピを実装するか、キュレーターのリーダー ラッチをすぐに使用することができます。バリアに関しては、ロックとどう違うのかわかりません。だから私は尋ねます：

• 私のマスター/スレーブまたはプライマリ/セカンダリの問題は、ZK のリーダー選出レシピの正確な使用例ですか?
• 分散ロックの例は何ですか? どのような問題を解決しますか?
• バリアについても同様です。ロックとバリアの違いは何ですか?

たとえば、N 個の物理マシンでビジネス ロジックを実行する P 個のプロセスがあるとします。これらのプロセスは、たとえば Web サービス S を呼び出します。すべての P プロセスを組み合わせて、サービス S に対して 1 秒あたり X 回以下の呼び出しが行われるようにしたいと考えています。

このようなソリューションはどのように実装できますか?

Google Guava の Rate Limiter は、単一のボックスで実行されているプロセスではうまく機能しますが、分散セットアップでは機能しません。

JAVA で利用できる、すぐに使用できる標準的なソリューションはありますか? [飼育係に基づいている可能性があります]

ありがとう！