apache-zookeeper - org - zookeeper why




Explicando o Apache ZooKeeper (3)

Eu estou tentando entender o ZooKeeper, como ele funciona e o que ele faz. Existe alguma aplicação que seja comparável ao ZooKeeper?

Se você sabe, então como você descreveria o ZooKeeper para um leigo?

Eu tentei apache wiki, sourceforge zookeeper ... mas eu ainda não sou capaz de se relacionar com isso.

Acabei de ler através de http://zookeeper.sourceforge.net/index.sf.shtml , então não há mais serviços como este? É tão simples como apenas replicar um serviço de servidor?


Em poucas palavras, o ZooKeeper ajuda você a construir aplicativos distribuídos.

Como funciona

Você pode descrever o ZooKeeper como um serviço de sincronização replicado com consistência eventual. Ele é robusto, já 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; contanto que uma maioria restrita de nós esteja funcionando, o conjunto de nós do ZooKeeper está ativo. Em particular, um nó mestre é escolhido dinamicamente por consenso dentro do conjunto; se o nó mestre falhar, a função do mestre será migrada para outro nó.

Como as gravações são tratadas

O mestre é a autoridade para as gravações: dessa maneira, as gravações podem ser garantidas como persistentes em ordem, isto é, as gravações são lineares . Cada vez que um cliente grava no conjunto, a maioria dos nós mantém as informações: esses nós incluem o servidor para o cliente e, obviamente, o principal. Isso significa que cada gravação torna o servidor atualizado 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 para o fato de o ZooKeeper não funcionar bem para cargas de trabalho dominantes para 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 ajuda você. Quando os dados podem ser gravados simultaneamente, o ZooKeeper realmente atrapalha, porque impõe um ordenamento estrito das operações, mesmo que não seja estritamente necessário do ponto de vista dos autores. Seu uso ideal é para coordenação, onde as mensagens são trocadas entre os clientes.

Como as leituras são tratadas

É aí 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 "visão" de um cliente pode estar desatualizada, já que 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 sob ele, formando praticamente um sistema de diretórios interno.

Znodes seqüenciais

Curiosamente, o nome de um znode pode ser sequencial , o que significa que o nome que o cliente fornece ao criar o znode é apenas um prefixo: o nome completo também é dado por um número seqüencial escolhido pelo conjunto. Isso é útil, por exemplo, para fins de sincronização: se vários clientes quiserem obter um bloqueio em um recurso, cada um deles poderá criar simultaneamente um znode sequencial em um local: quem receber o menor número terá direito ao bloqueio.

Znodes efêmeros

Além disso, um znode pode ser efêmero : isso significa que ele é 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 tomadas por um novo cliente. Tomando o exemplo do bloqueio, assim que o cliente com o bloqueio se desconecta, os outros clientes podem verificar se têm direito ao bloqueio.

Relógios

O exemplo relacionado à desconexão do cliente pode ser problemático se precisarmos periodicamente pesquisar o estado dos znodes. Felizmente, o ZooKeeper oferece um sistema de eventos onde 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 de uso do Zookeeper é o cálculo de memória distribuída, em que alguns dados são compartilhados entre nós clientes e devem ser acessados ​​/ atualizados de uma maneira muito cuidadosa para levar em conta 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ê tem ao usar um repositório de mensagens centralizado (como um broker).

O ZooKeeper é leve, o que significa que mecanismos como eleição de 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 cages e especialmente curator .

Onde ler mais

Além da documentação oficial, o que é muito bom, sugiro ler o Capítulo 14 do Hadoop: The Definitive Guide que tem ~ 35 páginas explicando essencialmente o que o ZooKeeper faz, seguido por um exemplo de serviço de configuração.


Eu entendo o ZooKeeper em geral, mas tive problemas com os termos "quorum" e "split brain", então talvez eu possa compartilhar minhas descobertas com você (eu me considero também um leigo).

Digamos que temos um cluster do ZooKeeper de 5 servidores. Um dos servidores se tornará o líder e os outros se tornarão seguidores.

  • Esses 5 servidores formam um quórum. O quórum simplesmente significa "esses servidores podem votar em quem deve ser o líder".

  • Então a votação é baseada na maioria. Maioria significa simplesmente "mais da metade", então mais da metade do número de servidores deve concordar que um servidor específico se torne o líder.

  • Então, existe essa coisa ruim que pode acontecer chamada "cérebro dividido". Um cérebro dividido é simplesmente isso, até onde eu entendo: o cluster de 5 servidores se divide em duas partes, ou vamos chamá-lo de "equipes de servidores", com talvez uma parte de 2 e a outra de 3 servidores. Esta é realmente uma situação ruim, como se ambas as "equipes de servidores" tivessem que executar uma ordem específica, como você decidiria qual equipe deveria ser preferida? Eles podem ter recebido informações diferentes dos clientes. Por isso, é realmente importante saber o que "equipe de servidores" ainda é relevante e qual deles pode / deve ser ignorado.

  • A maioria também é o motivo pelo qual você deve usar um número ímpar de servidores. Se você tem 4 servidores e um cérebro dividido, em que 2 servidores se separam, então as duas "equipes de servidores" podem dizer "ei, queremos decidir quem é o líder!" mas como você deve decidir quais 2 servidores você deve escolher? Com 5 servidores é simples: a equipe de servidores com 3 servidores tem a maioria e tem permissão para selecionar o novo líder.

  • Mesmo se você tiver apenas 3 servidores e um deles falhar, os outros 2 ainda formam a maioria e podem concordar que um deles se tornará o novo líder.

Eu percebo que uma vez que você pense sobre isso algum tempo e entenda os termos, não é mais tão complicado. Espero que isso também ajude alguém a entender esses termos.


O Zookeeper é um servidor de código aberto centralizado para manter e gerenciar informações de configuração, convenções de nomenclatura e sincronização para ambiente de cluster distribuído. O Zookeeper ajuda os sistemas distribuídos a reduzir sua complexidade de gerenciamento, fornecendo baixa latência e alta disponibilidade. O Zookeeper foi inicialmente um subprojeto do Hadoop, mas agora é um projeto independente de alto nível da Apache Software Foundation.

Mais Informações