Выборы лидера: Etcd против Zookeeper против Hazelcast

Question

Мы выбираем лучший вариант для реализации выбора лидера для нашего сервиса (написанного на Java), состоящего из нескольких (например, 3) экземпляров для обеспечения высокой доступности.Наша цель состоит в том, чтобы в любой момент времени был активен только один экземпляр.

Было бы здорово узнать ваше мнение о следующих параметрах:

1) Hazelcast.Используя «кворум» и блокировку, мы можем осуществить выборы лидера.Однако мы можем столкнуться с проблемой раздвоения мозга, когда в течение некоторого времени могут присутствовать два лидера.Также кажется, что Hazelcast не поддерживает SSL.

2) Zookeeper.Мы можем реализовать выбор лидера поверх ансамбля Zookeeper (где ZK-узел запускается в каждом экземпляре нашего сервиса).Предоставляет ли Zookeeper лучшие гарантии согласованности, чем Hazelcast?Он также страдает от проблемы с разделенным мозгом?

3) И т.д.Мы можем использовать библиотеку Jetcd, которая кажется самой современной и надежной технологией.Это действительно лучше с точки зрения согласованности, чем Zookeeper?

Спасибо.

Answer 1

1) В настоящее время Hazelcast не подходит для выборов лидеров.Как вы уже упоминали, он может выбирать доступность во время разделения сети, что может привести к избранию нескольких лидеров.

Существует активная разработка по построению атомарности Hazelcast (блокировка, семафор, атомарная длина и т. Д.) С использованием Raft консенсус внутри кластера Hazelcast.Ожидается, что он будет выпущен в одном из следующих выпусков.

2) Zookeeper не страдает от упомянутой проблемы разделения мозга, вы не увидите нескольких лидеров, когда произойдет разделение сети.Zookeeper построен на ZAB протоколе атомного вещания.

3) Etcd использует Raft консенсусный протокол.Raft и ZAB имеют одинаковые гарантии согласованности, которые могут быть использованы для реализации процесса выборов лидера.