Обзор возможностей библиотеки Apache Curator для Apache Zookeeper
Комментарии (6)
2 августа 2017 в 10:15
–1↑
↓
В новых проектах не вижу смысла в использовании ZK, когда есть etcd.
Когда допилят zetcd, ZK станет не нужным и в старых проектах.
ivankudryavtsev
2 августа 2017 в 10:29
0↑
↓
К сожалению, я не знаком детально с etcd. Мне кажется, что etcd — это больше про конфигурацию и discovery, в этом смысле его разумнее сравнивать с consul, а zookeeper, в контексте данной статьи, — про координацию.Кроме того, согласно статье он только в последних версиях начал поддерживать DLM, что требует проведения бенчмарков, как минимум для того, чтобы объективно выбрать решение. Многие вещи можно и на in-memory grid делать — на том же Hazelcast, Ignite, да хоть на MySQL, но здесь речь про Apache Zookeeper.
Честно говоря, не думаю, что все бросятся переходить на etcd. Причин несколько, одна из существенных — если у вас развернута инфраструктура, в которой уже есть Zookeeper, а таких инфраструктур много, то проще продолжать использовать его, нежели переходить на другую систему.
2 августа 2017 в 10:49
0↑
↓
Собственно, как заказывали :)
https://coreos.com/blog/performance-of-etcd.html
Вообще, моек мнение было — выбор сервиса координации с точки зрения operations.
мейнтейнить ZK не очень удобно, exhibitor мертв, да и вообще, судя по темпу развития 3.5 ветки, проект в стагнации.-
ivankudryavtsev
2 августа 2017 в 10:54 (комментарий был изменён)
0↑
↓
Все верно, но это не производительность для целей координации, а для конфигурации. Видел этот обзор. Я же говорю, меня Zookeeper для целей конфигурации меньше интересует, чем возможности для координации. Об этом статья и написана.Еще раз, я не говорю, что Etcd плохой, а Zookeeper хороший.
AstarothAst
2 августа 2017 в 11:32
0↑
↓
Я не совсем понял, есть ли у ZooKeeper’а возможность разворачиваться не отдельным сервером, а в embedded виде? Ну, то есть пишу я приложение, и хочу иметь возможность обновляться без остановки оного. Поднимаю два экземпляра, у каждого внутри стартован экземпляр zookeeper’а, эти экземпляры здороваются, и ноды могут друг про друга все узнавать — умерла одна, вторая начала процессить запросы, первая обновилась, сказала «я главная», поменялись местами. Или я хочу странного?-
ivankudryavtsev
2 августа 2017 в 11:49
0↑
↓
Лучший ответ на ваш вопрос вот здесь — серверы должны знать о друг друге заранее.То, что Вы хотите, можно реализовать на Hazelcast, к примеру, там есть динамическое присоединение к кластеру.
