で飼育係クライアント（4） -キュレーター、我々はノード操作クライアントの学芸員だけでなく、非同期処理、トランザクション操作を導入しましたが、我々はないではないかキュレーター内のノードへの変更をリッスンするために、そしてZkClient類似し、繰り返しリスニングを避けるために、キュレーターキャッシュは、キュレーターでのイベント監視用のパッケージです。イベントの監視は、ローカルキャッシュビューとリモートズーキーパービューの比較プロセスとして表示できます。
- NodeCache：ノードキャッシュは、ノード自体の変更を処理するために使用されます。コールバックインターフェースNodeCacheListener
- PathChildrenCache：子ノードキャッシュは、ノードの子ノードの変更を処理するために使用され、コールバックインターフェースPathChildrenCacheListener
- TreeCache： NodeCacheとPathChildrenCacheの組み合わせ、コールバックインターフェイスTreeCacheListener
NodeCache
まず、NodeCacheを見てみましょう。前回紹介したキュレーターからZookeeperへの手順に従います。最初に、まずZookeeperに接続し、次のようにリスナーを追加します。
public class CuratorTest {
private static final String CONNENT_ADDR = "192.168.80.130:2181";
public static void main(String[] args) throws Exception {
CuratorFramework curatorFramework = CuratorFrameworkFactory.builder()
.connectString(CONNENT_ADDR)
.connectionTimeoutMs(5000) //连接超时时间
.sessionTimeoutMs(5000) //会话超时时间
.retryPolicy(new ExponentialBackoffRetry(1000, 3))
.build();
curatorFramework.start();
final NodeCache cache = new NodeCache(curatorFramework, "/node1", false);
cache.start(); //需要调用nodeCache的start方法能进行缓存和事件监听
cache.getListenable().addListener(new NodeCacheListener() {
//监听节点变化
@Override
public void nodeChanged() throws Exception {
System.out.println("路径为：" + cache.getCurrentData().getPath());
System.out.println("数据为：" + new String(cache.getCurrentData().getData()));
System.out.println("状态为：" + cache.getCurrentData().getStat());
}
});
curatorFramework.create()
.creatingParentsIfNeeded()
.withMode(CreateMode.PERSISTENT)
.forPath("/node1", "value".getBytes());
Thread.sleep(1000);
}
}
最初のパラメーターは作成されたキュレーターに渡されるフレームクライアント、2番目のパラメーターはリスニングノードのパス、3番目のオーバーロードパラメーターdataIsCompressedはデータを圧縮するかどうかを示します。最後に、NodeCacheのstartメソッドを呼び出して、キャッシュとイベントの監視を実行する必要があります。
ここで、NodeCacheによって監視されているノードが空の場合（つまり、着信パスが存在しない場合）がわかります。その後、対応するノードを後で作成すると、イベントがトリガーされ、nodeChangedメソッドがコールバックされます。
さらに、起動ノードのイベント監視メソッドcache.start（）は、次のようにデフォルトでfalseになっているパラメーターも渡すことができます。
void start（boolean buildInitial）// trueは現在のノードをキャッシュすることを意味します
唯一のパラメーターbuildInitialは、ノードのデータをすぐにキャッシュするかどうかを表します。trueに設定した場合、startを開始した直後にNodeCacheのGetCurrentDataメソッドを呼び出すことで、対応するノードChildDataクラスの情報を取得できます。falseに設定した場合、対応する情報を取得できません。
上記のようにfalseをテストする場合は、前にスリープ時間を追加してみてください。そうしないと、間隔が短すぎてイベントをトリガーするだけなので、期待した結果が得られない場合があります。
PathChildrenCache
キュレーターリスニングノードの変更を理解した後、キュレーターが子ノードの追加、変更、削除をどのようにリスニングするかを見てみましょう
public class CuratorTest {
private static final String CONNENT_ADDR = "192.168.80.130:2181";
public static void main(String[] args) throws Exception {
CuratorFramework curatorFramework = CuratorFrameworkFactory.builder()
.connectString(CONNENT_ADDR)
.connectionTimeoutMs(5000) //连接超时时间
.sessionTimeoutMs(5000) //会话超时时间
.retryPolicy(new ExponentialBackoffRetry(1000, 3))
.build();
curatorFramework.start();
final PathChildrenCache cache = new PathChildrenCache(curatorFramework, "/node1", true);
cache.start(PathChildrenCache.StartMode.POST_INITIALIZED_EVENT);//只有POST_INITIALIZED_EVENT模式才会启用监听功能
cache.getListenable().addListener(new PathChildrenCacheListener() {
//监听子节点的变化
@Override
public void childEvent(CuratorFramework cf, PathChildrenCacheEvent event) throws Exception {
switch (event.getType()) {
case CHILD_ADDED: //新增
System.out.println("新增子节点路径：" + event.getData().getPath());
System.out.println("新增子节点数据：" + new String(event.getData().getData()));
break;
case CHILD_UPDATED: //更新
System.out.println("更新子节点路径：" + event.getData().getPath());
System.out.println("更新子节点数据：" + new String(event.getData().getData()));
break;
case CHILD_REMOVED: //移除
System.out.println("移除子节点路径：" + event.getData().getPath());
System.out.println("移除子节点数据：" + new String(event.getData().getData()));
break;
default:
break;
}
}
});
curatorFramework.create()
.creatingParentsIfNeeded()
.withMode(CreateMode.PERSISTENT)
.forPath("/node1/n1", "v1".getBytes());
Thread.sleep(2000);
}
}
ここでは少し注意を払っていますが、これは下の図の3番目のパラメーターcacheDataであり、これは上で紹介したNodeCacheとは異なり、ノードのコンテンツをキャッシュするかどうかを示します。cacheDataがtrueの場合、ノードのコンテンツは、ノードリスト変更イベントが受信されると同時に取得されます。
さらに、PathChildrenCacheListenerのインスタンスを作成した後、このインスタンスをPathChildrenCacheキャッシュインスタンスに登録し、キャッシュインスタンスのaddListenerメソッドを使用する必要があります。次に、キャッシュインスタンスnodeCacheのstartメソッドを使用して、ノードのイベント監視を開始します。
ここでのstartメソッドは、開始モードで渡す必要があります。3つのモードを導入できます。
-
NORMAL：非同期初期化キャッシュが
開始されると、キャッシュは非同期に初期化され、完了後に通知は発行されません。 -
BUILD_INITIAL_CACHE：同期初期化キャッシュ
が開始すると、同期初期化キャッシュが作成され、キャッシュを作成した後、対応するデータをサーバーからプルします。 -
POST_INITIALIZED_EVENT：非同期でキャッシュを初期化し、完了イベントをトリガーします。
起動時に、非同期でキャッシュを初期化します。初期化の完了により、PathChildrenCacheEvent.Type＃INITIALIZEDイベントがトリガーされます。キャッシュ内のリスナーは、イベントの通知を受け取ります。
さらに、PathChildrenCacheは子ノードの追加、変更、削除を監視し、基本的にZkClientと同様です。
- 現在のノードではなく、子ノードのみをリッスンできます
- 再帰的にリッスンできません。子ノードの下の子ノードは再帰的に監視できません
しかし、ここにはわずかな違いがあります。ZkClientでは、子ノードの下で子ノードを操作しています。リスナーにはトリガーイベントがありませんが、キュレーターでは、子ノードの下で子ノードを操作しています。次のように感じられますが、子ノードの下の子ノードの情報を取得できません。
TreeCache
上記では、NodeCacheを使用してZNode自体を監視しています。ZNodeノード自体が作成、更新、または削除された場合、ノードキャッシュはキャッシュを更新し、登録済みリスナーに対してイベントをトリガーします。リスナーに対応するインターフェースはNodeCacheListenerです。
PathChildrenCache子ノードキャッシュは、ZNodeの子ノードを監視し、子ノードの状態をキャッシュするために使用されます。ZNodeの子ノードが作成、更新、または削除されると、PathChildrenCacheはキャッシュを更新し、登録済みリスナーに対してイベントをトリガーします。インターフェースはPathChildrenCacheListenerです。
TreeCacheは上記の2つの組み合わせとして見ることができ、TreeCacheは現在のZNodeノードのすべてのデータを監視します。TreeCacheは、子ノードだけでなく、ノード自体も監視できます。
その使用法は、ノードの追加、変更、削除に対応することを除いて、基本的にPathChildrenCacheに似ていますが、TreeCacheのイベントタイプのメソッド名は異なります。
