zookeeper watchメカニズムの理解


まず、なぜウォッチを追加したのか見てみます。
Zoo Keeperは分散プロセスを調整(同期)するためのサービスであり、単純で高性能な協調カーネルを提供し、ユーザーはそれ以上に複雑な分散協調機能を構築することができる。
複数の分散プロセスは、ZooKeeperによって提供されたAPIによって共有されたZoo KeeperメモリデータオブジェクトZNodeを操作して、ある種の一致した挙動または結果を達成する。このパターンは本質的に状態共有の同時モデルに基づいており、Javaのマルチスレッド同時モデルと一致し、スレッドまたはプロセスはすべて「共有メモリ通信」である。Javaは、あるオブジェクトの状態の変化を監視する応答式通知インターフェースを直接提供していません。CPU時間の無応答ポーリング再試行を無駄にしたり、Javaによって提供されたある種のアクティブ通知(Notif)機構(内蔵キュー)に基づいて状態変化に応答したりするしかないですが、このメカニズムは、ループブロッキングの呼び出しが必要です。Zoo Keeperは、これらの分散プロセスの状態(ZNodeのData、Children)共有を実現する際に、性能の考慮に基づいて、類似の非同期非ブロッキングのアクティブ通知モードであるWatchメカニズムを採用して、分散プロセス間の「共有状態通信」がよりリアルタイムで効率的になるようにするが、これもZoo Keeperの主要なタスクによる協調である。
すべてのZookeeperは操作を読んで、getData()、get Children()とexists()を含んで、すべてスイッチがあって、操作の同時にもう一つのwatchを設けることができます。Zoo Keeperでは、Watchはワンタッチセンサーであり、watchが設定されているデータが変化したときに、watchが設定されているクライアントに送信されます。ウォッチの定義には三つのポイントがあります。
使い捨てのトリガー
一つのウォッチイベントはデータが変更された時にクライアントに送信されます。例えば、クライアントが操作getDataを実行すると、その後/znode 1が変更されたり削除されたりして、クライアントは一つ/znode 1のウォッチイベントを得ることができます。もし/znode 1が再度変更されたら、クライアントに新しいウオッチが設定されていない場合、このクライアントにウオッチイベントを送信しないです。
クライアントに送信
つまり、イベントはクライアントに送信されますが、動作が正常に戻り値が変更されたクライアントに到達する前に、このイベントはまだwatchのクライアントに送信されていません。Watchは非同期で送信されます。しかし、Zoo Keeperは、watchイベントを受信する前に、必ずwatchの値の変動を見ないようにする順序を保証しています。ネットワークの待ち時間と他の要因は、異なるクライアントがウォッチを見たり、リターン値を更新したりする時間が違ってくる可能性がある。しかし肝心な点は、各クライアントが見ているすべてのことに順序があります。
ウォッチが設置されたデータ
これはノードに変動が生じる異なる方式を指す。Zoo Keeperは二つのwatchリストを守ったと考えられます。data watchとchild watch。getData()とexists()はdata watchをセットし、get Children()はchild watchをセットします。あるいは、ウォッチは戻り値によって設定されていると考えられています。get Data()とexists()はノード自体の情報を返し、get Children()はサブノードのリストを返す。したがって、setData()はznodeに設置されたdata watchをトリガします。一つの成功create()操作は、作成されたznode上のデータウオッチと、その親ノードのchild watchをトリガします。成功したのはdelete()操作はznodeのdata watchとchild watchを同時にトリガします。同時に、親ノードのchild watchもトリガします。
Watchはclientに接続されたZoo Keeperサーバーでローカルにメンテナンスされています。このように設定、メンテナンス、ウォッチの支出を低減することができる。一つのクライアントが新しいサーバに接続されると、watchは任意のセッションイベントでトリガされる。一つのサーバーと接続を失うと、ウォッチは受信できません。clientが再接続する時、必要ならば、以前登録したwatchは全部再登録されます。普通はこれは完全に透明です。一つの特殊な場合にのみ、watchは失われる可能性があります。未作成のznodeのexist watchに対して、クライアントが接続を切断している間に作成された場合、またクライアント接続の上の前で削除された場合、このwatchイベントは失われる可能性があります。
Zoo KeeperはWatchに対して何か保障を提供していますか?
ウォッチに対して、Zoo Keeperはこれらの保障を提供しています。
Watchと他のイベント、他のwatchと非同期回復は秩序があります。Zoo Keeperクライアントライブラリは、すべてのイベントが順次配信されることを保証します。クライアントは、対応するznodeの新しいデータを見る前にwatchイベントを受信することを保証します。Zoo Keeperから受け取ったwatchイベントの順番は必ずZoo Keeperサービスから見たイベントの順番と一致しています。
Watchについて注意すべきことがあります。
Watchは使い捨てのフリップフロップです。もしウォッチ事件を得たら、今後変更が発生した時に引き続き通知してほしいです。ウォッチをもう一つ設置してください。
watchは使い捨ての触発器であるため、イベントを取得してからwatchを再送信するという要求はこのプロセスに遅延があるので、Zoo Keeper上で発生したすべてのノードのイベントを見たことは保証できません。この時間の窓口で何度もznodeの変更が発生する可能性がありますので、ご了承ください。処理しなくてもいいですが、少なくともこの点を認識してください。
一つのウォッチオブジェクトまたは関数/コンテキストペアは、一つのイベントのために一回だけ通知されます。例えば、同じwatchオブジェクトが同じファイル上でexistsとgetDataによって二回登録されていますが、このファイルはその後削除されました。このwatchオブジェクトは一回だけそのファイルのdeletion通知を受けます。
サーバーから切断すると(サーバーが故障したなど)、再度上の前に接続すると、何のwatchも獲得できなくなります。これらの会話イベントを使ってセキュリティモードにしてください。disconnectedの状態ではイベントは受信されませんので、その間は慎重に実行してください。
締め括りをつける
以上がこの記事のzookeeper watchのメカニズムについて紹介しました。興味のある友達はzookeeperに対応するacl権限を設定するapphe zookeeper使用方法の例を詳しく説明する。などを参照してください。