https://zookeeper.apache.org/doc/current/zookeeperOver.html
Por padrão, o Zookeeper replica todos os seus dados para cada nó e permite que os clientes observem as alterações nos dados. As alterações são enviadas muito rapidamente (dentro de um período de tempo limitado) aos clientes. Você também pode criar "nós efêmeros", que são excluídos dentro de um tempo especificado se um cliente se desconectar. O ZooKeeper é altamente otimizado para leituras , enquanto as gravações são muito lentas (já que geralmente são enviadas para todos os clientes assim que a gravação ocorre). Finalmente, o tamanho máximo de um "arquivo" (znode) no Zookeeper é de 1 MB, mas normalmente serão strings únicas.
Em conjunto, isso significa que o zookeeper não deve armazenar muitos dados e, definitivamente, não um cache. Em vez disso, é para gerenciar batimentos cardíacos/saber quais servidores estão online, armazenar/atualizar configuração e possivelmente passar mensagens (embora se você tiver grandes #s de mensagens ou demandas de alta taxa de transferência, algo como RabbitMQ será muito melhor para essa tarefa).
Basicamente, o ZooKeeper (e o Curator, que é construído sobre ele) ajuda a lidar com a mecânica do clustering - pulsações, distribuição de atualizações/configuração, bloqueios distribuídos, etc.
Não é realmente comparável ao Redis, mas para as perguntas específicas...
-
Ele não suporta nenhum cálculo e, para a maioria dos conjuntos de dados, não poderá armazenar os dados com desempenho.
-
Ele é replicado para todos os nós do cluster (não há nada como o cluster Redis onde os dados podem ser distribuídos). Todas as mensagens são processadas atomicamente na íntegra e são sequenciadas, portanto, não há transações reais. Ele pode ser USADO para implementar bloqueios em todo o cluster para seus serviços (na verdade, é muito bom nisso), e existem muitas primitivas de bloqueio nos próprios znodes para controlar quais nós os acessam.
-
Claro, mas o ZooKeeper preenche um nicho. É uma ferramenta para fazer com que aplicativos distribuídos funcionem bem com várias instâncias, não para armazenar/compartilhar grandes quantidades de dados. Comparado ao uso de um IMDG para esta finalidade, o Zookeeper será mais rápido, gerencia os heartbeats e a sincronização de forma previsível (com muitas APIs para facilitar esta parte), e possui um paradigma "push" em vez de "pull" para que os nós sejam notificado muito rapidamente das alterações.
A citação da pergunta vinculada ...
Um exemplo canônico do uso do Zookeeper é a computação de memória distribuída
... é, IMO, um pouco enganador. Você o usaria para orquestrar a computação, não para fornecer os dados. Por exemplo, digamos que você tenha que processar as linhas de 1 a 100 de uma tabela. Você pode colocar 10 nós ZK, com nomes como "1-10", "11-20", "21-30", etc. Os aplicativos clientes seriam notificados dessa mudança automaticamente pelo ZK, e o primeiro pegaria " 1-10" e defina um nó efêmero
clients/192.168.77.66/processing/rows_1_10 A próxima aplicação veria isso e iria para o próximo grupo processar. Os dados reais a serem computados seriam armazenados em outro lugar (ou seja, Redis, banco de dados SQL etc.). Se o nó falhar no meio do cálculo, outro nó poderá ver isso (após 30 a 60 segundos) e retomar o trabalho.
Eu diria que o exemplo canônico do ZooKeeper é a eleição do líder, no entanto. Digamos que você tenha 3 nós - um é mestre e os outros 2 são escravos. Se o mestre cair, um nó escravo deve se tornar o novo líder. Esse tipo de coisa é perfeito para ZK.
