Em poucas palavras, o ZooKeeper ajuda a criar aplicativos distribuídos.
Como funciona
Você pode descrever o ZooKeeper como um serviço de sincronização replicado com consistência eventual. É robusto, uma vez que os dados persistentes são distribuídos entre vários nós (esse conjunto de nós é chamado de "conjunto") e um cliente se conecta a qualquer um deles (ou seja, um "servidor" específico), migrando se um nó falhar; Enquanto a maioria estrita dos nós estiver funcionando, o conjunto de nós do ZooKeeper estará ativo. Em particular, um nó principal é escolhido dinamicamente por consenso dentro do conjunto; se o nó principal falhar, a função de mestre será migrada para outro nó.
Como as gravações são tratadas
O mestre é a autoridade para gravações: dessa maneira, pode-se garantir que as gravações sejam mantidas em ordem, ou seja, gravações são lineares . Cada vez que um cliente grava no conjunto, a maioria dos nós persiste as informações: esses nós incluem o servidor para o cliente e, obviamente, o mestre. Isso significa que cada gravação atualiza o servidor com o mestre. Isso também significa, no entanto, que você não pode ter gravações simultâneas.
A garantia de gravações lineares é a razão do fato de o ZooKeeper não ter um bom desempenho para cargas de trabalho dominantes na gravação. Em particular, não deve ser usado para intercâmbio de dados grandes, como mídia. Desde que sua comunicação envolva dados compartilhados, o ZooKeeper o ajudará. Quando os dados podem ser gravados simultaneamente, o ZooKeeper realmente atrapalha, porque impõe uma ordem estrita de operações, mesmo que não seja estritamente necessário da perspectiva dos escritores. Seu uso ideal é para coordenação, onde as mensagens são trocadas entre os clientes.
Como as leituras são tratadas
É aqui que o ZooKeeper se destaca: as leituras são simultâneas, pois são atendidas pelo servidor específico ao qual o cliente se conecta. No entanto, esse também é o motivo da consistência eventual: a "visualização" de um cliente pode estar desatualizada, pois o mestre atualiza o servidor correspondente com um atraso limitado mas indefinido.
Em detalhe
O banco de dados replicado do ZooKeeper compreende uma árvore de znodes , que são entidades que representam aproximadamente os nós do sistema de arquivos (pense neles como diretórios). Cada znode pode ser enriquecido por uma matriz de bytes, que armazena dados. Além disso, cada znode pode ter outros znodes, praticamente formando um sistema de diretório interno.
Znodes sequenciais
Curiosamente, o nome de um znode pode ser seqüencial , o que significa que o nome que o cliente fornece ao criar o znode é apenas um prefixo: o nome completo também é fornecido por um número sequencial escolhido pelo conjunto. Isso é útil, por exemplo, para fins de sincronização: se vários clientes desejam obter um bloqueio em um recurso, cada um pode criar simultaneamente um znode seqüencial em um local: quem obtém o número mais baixo tem direito ao bloqueio.
Znodes efêmeros
Além disso, um znode pode ser efêmero : isso significa que é destruído assim que o cliente que o criou se desconecta. Isso é útil principalmente para saber quando um cliente falha, o que pode ser relevante quando o próprio cliente tem responsabilidades que devem ser assumidas por um novo cliente. Tomando o exemplo do bloqueio, assim que o cliente com o bloqueio for desconectado, os outros clientes poderão verificar se têm direito ao bloqueio.
Relógios
O exemplo relacionado à desconexão do cliente pode ser problemático se for necessário pesquisar periodicamente o estado dos znodes. Felizmente, o ZooKeeper oferece um sistema de eventos em que um relógio pode ser configurado em um znode. Esses relógios podem ser configurados para acionar um evento se o znode for especificamente alterado ou removido ou se novos filhos forem criados sob ele. Isso é claramente útil em combinação com as opções seqüenciais e efêmeras para znodes.
Onde e como usá-lo
Um exemplo canônico do uso do Zookeeper é o cálculo da memória distribuída, onde alguns dados são compartilhados entre os nós do cliente e devem ser acessados / atualizados de uma maneira muito cuidadosa para considerar a sincronização.
O ZooKeeper oferece a biblioteca para construir suas primitivas de sincronização, enquanto a capacidade de executar um servidor distribuído evita o problema de ponto único de falha que você possui ao usar um repositório de mensagens centralizado (semelhante a um broker).
O ZooKeeper é leve, o que significa que mecanismos como eleição do líder, bloqueios, barreiras etc. ainda não estão presentes, mas podem ser escritos acima das primitivas do ZooKeeper. Se a API C / Java for muito pesada para seus propósitos, você deve confiar em bibliotecas criadas no ZooKeeper, como gaiolas e, principalmente, curador .
Onde ler mais
Além da documentação oficial, o que é bastante bom, sugiro ler o Capítulo 14 do Hadoop: O Guia Definitivo, que possui ~ 35 páginas explicando essencialmente o que o ZooKeeper faz, seguido de um exemplo de serviço de configuração.