Я пытаюсь создать приложение на основе Zookeeper с CuratorFramework. Приложение должно иметь возможность запускать кворум на нескольких узлах. Каждый экземпляр приложения имеет встроенный экземпляр сервера и клиентов Zookeeper. Узлы успешно собраны в кворуме. Каждый узел записывает узел EPHEMERAL в/workers/active/node1 («active» - это PERSISTENT znode, созданный лидером). Поскольку Zookeeper обнаруживает очень медленный сбой узла и эфемерного узла, исчез после истечения срока действия сеанса, когда клиент был подключен к экземпляру localhost-сервера zookeeper, я решил подключить клиента NodeA к кластеру со строкой соединения «NodeB, NodeC». NodeB со строкой соединения «NodeA, Node C» и NodeC с «NodeA, NodeB». Это приводит к тому, что кластер намного быстрее обнаруживает отказ узла. Я добавил наблюдателя на каждый узел, чтобы обнаружить событие NodeChildren on/workers/active. Этот наблюдатель имеет специальный экземпляр клиента CuratorFramework, подключенного к локальному серверу zookeeper. Я сделал это так, потому что обратный вызов зарегистрирован только на сервере, где клиент зарегистрировал его. Проблема в том, что это решение нестабильно, и я не знаю, почему. Иногда все работает правильно, но после этого я теряю znode в/employees/active, но все узлы запущены или состояние в/employees/active правильно, но обратный вызов NodeChildren не работает, даже если он работал правильно несколько секунд назад. .. Что я могу сделать неправильно? Я пробовал все ...Cluster Monitor с Zookeeper
0
A
ответ
0
Я нашел сульфику.
В моем случае это лучший вариант использования PersistentEphemeral узел из рецептов куратора для регистрации узлов.
Для обратных вызовов, которые обнаруживают добавлять/удалять узлы лучше использовать PathChildrenCache из CuratorFramework рецептов и prepand обратного вызова к нему