Zookeeper vs In-memory-data-grid vs Redis

Question

Я нашел различные определения для zookeeper для нескольких ресурсов. Может быть, некоторые из них взяты из контекста, но смотреть на них пожалуйста:

1. A canonical example of Zookeeper usage is distributed-memory computation...

2. ZooKeeper is an open source Apache™ project that provides a centralized infrastructure and services that enable synchronization across a cluster.

3. Apache ZooKeeper is an open source file application program interface (API) that allows distributed processes in large systems to synchronize with each other so that all clients making requests receive consistent data.

Я работал с Redis и Hazelcast, мне было бы легче понять Zookeeper, сравнив его с ними.

Не могли бы вы сравнить Zookeeper с сетями данных-данных и Redis?

1. Если вычисление с распределенной памятью, то как zookeeper отличается от сетки данных в памяти?
2. Если синхронизация между кластерами, чем она отличается от всех других хранилищ в памяти? Те же сетки данных в памяти также обеспечивают блокировку всего кластера. У Redis также есть какие-то транзакции.
3. Если речь идет только о согласованных данных в памяти, чем другие альтернативы. Imdg позволяет вам достичь того же, не так ли?

Answer 1

https://zookeeper.apache.org/doc/current/zookeeperOver.html

По умолчанию Zookeeper копирует все данные на каждый узел и позволяет клиентам наблюдать данные изменения. Изменения отправляются очень быстро (в течение ограниченного промежутка времени) клиентам. Вы также можете создавать «эфемерные узлы», которые удаляются в течение определенного времени, если клиент отключается. ZooKeeper очень оптимизирован для :, в то время как записи происходят очень медленно (поскольку они обычно отправляются каждому клиенту, как только происходит запись). Наконец, максимальный размер «файла» (znode) в Zookeeper равен 1 МБ, но обычно они будут одиночными.

Взятый вместе, это означает, что zookeeper не предназначен для хранения большого количества данных, и определенно не кэш. Вместо этого он предназначен для управления биениями/зная, какие серверы находятся в сети, сохраняя/обновляя конфигурацию и, возможно, передачу сообщений (хотя, если у вас есть большое количество сообщений или высокая пропускная способность, что-то вроде RabbitMQ будет намного лучше для этой задачи).

В основном, Zookeeper (и куратор, который построен на ней) помогает в обработке механики кластеризации - сердцебиения, распространение обновлений/конфигурация, распределенные замков и т.д.

Это не совсем сопоставим с Redis, но для конкретных вопросов ...

1. Он не поддерживает никаких вычислений и для большинства наборов данных, не будет иметь возможность хранить данные с любой производительностью.

2. Реплицируется на все узлы кластера (нет ничего похожего на кластеризацию Redis, где данные могут быть распределены). Все сообщения обрабатываются атомарно в полном объеме и упорядочены, поэтому реальных транзакций нет. Его можно использовать для реализации кластерных блокировок для ваших сервисов (на самом деле это очень хорошо), и в них много фиксирующих примитивов самих зномов, чтобы контролировать, какие узлы к ним обращаются.

3. Конечно, но ZooKeeper заполняет нишу. Это инструмент для того, чтобы распределенные приложения играли хорошо с несколькими экземплярами, а не для хранения/совместного использования больших объемов данных. По сравнению с использованием IMDG для этой цели Zookeeper будет быстрее, управляет биениями и синхронизацией предсказуемым способом (с большим количеством API-интерфейсов для упрощения этой части), и вместо «тянуть» есть парадигма «push», поэтому узлы очень быстро уведомлены об изменениях.

цитата из связанного вопроса ...

Канонический пример использования Zookeeper является распределенной памятью вычислений

... есть, IMO, немного вводит в заблуждение. Вы использовали бы его для организации вычислений, а не для предоставления данных. Например, скажем, вам пришлось обрабатывать строки 1-100 таблицы. Вы можете добавить 10 узлов ZK с именами типа «1-10», «11-20», «21-30» и т. Д. Клиентские заявки будут автоматически уведомлены об этом изменении ZK, а первая будет захватывать " 1-10 "и установите эфемерный узел clients/192.168.77.66/processing/rows_1_10

Следующее приложение увидит это и перейдет к следующей группе для обработки. Фактические данные для вычисления будут храниться в другом месте (например, Redis, база данных SQL и т. Д.). Если узел провалился через вычисление, другой узел мог увидеть это (через 30-60 секунд) и снова забрать задание.

Я бы сказал, что канонический пример ZooKeeper - это выбор лидеров. Предположим, у вас есть 3 узла - один - мастер, а второй 2 - подчиненные. Если мастер идет вниз, подчиненный узел должен стать новым лидером. Этот тип идеально подходит для ZK.