Hazelcast (Java) и ETCD (golang) различия / сходства?
Сейчас мы создаем аналитическую систему в реальном времени, и она должна быть высоко распределена. Мы планируем использовать распределенные блокировки и счетчики для обеспечения согласованности данных, и нам нужна какая-то распределенная карта, чтобы знать, какой клиент подключен к какому серверу. До этого у меня не было опыта работы с распределенными системами, но я думаю, что у нас есть два варианта:
Java + Hazelcast
Golang + ETCD
Но каковы плюсы / минусы друг друга в контексте темы?
1 ответ
Hazelcast и т. Д. - две совершенно разные системы. Причина в теореме CAP.
Теорема CAP гласит, что ни одна распределенная система не может иметь согласованность, доступность и устойчивость к разделам. Распределенные системы обычно находятся ближе к CA или CP. Hazelcast - это система AP, а etcd (реализация Raft) - это CP. Итак, ваш выбор между согласованностью и доступностью / производительностью.
В целом, Hazelcast будет гораздо более производительным и сможет обрабатывать больше сбоев, чем Raft и т. Д., Но за счет возможной потери данных или проблем с согласованностью. Принцип работы Hazelcast заключается в разделении данных и хранении фрагментов данных на разных узлах. Таким образом, в кластере из 5 узлов ключ "foo" может храниться на узлах 1 и 2, а столбец может храниться на узлах 3 и 4. Вы можете контролировать количество узлов, на которые Hazelcast реплицирует данные, через Hazelcast и карту. конфигурации. Однако во время сетевого или другого сбоя существует некоторый риск того, что вы увидите старые данные или даже потеряете их в Hazelcast.
В качестве альтернативы, Raft и т. Д. - это высокосогласованная система с одним лидером, которая сохраняет данные на всех узлах. Это означает, что он не идеален для хранения большого количества состояния. Но даже во время сбоя сети etcd может гарантировать, что ваши данные останутся непротиворечивыми. Другими словами, вы никогда не увидите старые / устаревшие данные. Но это обходится дорого. Системы CP требуют, чтобы большинство кластеров были живы для нормальной работы.
Проблема согласованности может относиться или не относиться к базовому хранилищу ключ-значение, но она может быть чрезвычайно важна для блокировок. Если вы ожидаете, что ваши блокировки будут согласованы во всем кластере - то есть только один узел может удерживать блокировку даже во время сбоя сети или другого сбоя - не используйте Hazelcast. Поскольку Hazelcast жертвует согласованностью в пользу доступности (опять же, см. Теорему CAP), вполне возможно, что сбой сети может привести к тому, что два узла поверит, что блокировка может быть получена бесплатно.
В качестве альтернативы, Raft гарантирует, что во время сбоя в сети только один узел останется лидером кластера etcd, и поэтому все решения принимаются через этот один узел. Это означает, что etcd может гарантировать постоянное представление состояния кластера и гарантировать, что что-то вроде блокировки может быть получено только одним процессом.
На самом деле, вам нужно рассмотреть то, что вы ищете в своей базе данных и пойти искать это. Варианты использования хранилищ данных CP и AP сильно различаются. Если вам нужна согласованность для хранения небольшого количества состояний, согласованных блокировок, выборов лидеров и других инструментов координации, используйте систему CP, такую как ZooKeeper или Consul. Если вам нужна высокая доступность и производительность при потенциальной стоимости согласованности, используйте Hazelcast или Cassandra или Riak.
Источник: я являюсь автором реализации Raft
Хотя этому вопросу уже более 3 лет, я хотел бы сообщить последующим читателям, что Hazelcast с 3.12 имеет подсистему на основе CP (на основе Raft) для своих API-интерфейсов Atomics и Concurrency. В ближайшем будущем планируется внедрить CP в большее количество структур данных Hazelcast. Предоставление пользователям Hazelcast истинного выбора между проблемами AP и CP и предоставление пользователям возможности применять Hazelcast для новых сценариев использования, которые ранее обрабатывались такими системами, как etcd и Zookeeper.
Вы можете прочитать больше здесь...
https://hazelcast.com/blog/hazelcast-imdg-3-12-beta-is-released/