Zookeeper - Fluxo de Trabalho

Depois que um conjunto ZooKeeper é iniciado, ele espera que os clientes se conectem. Os clientes se conectarão a um dos nós no conjunto ZooKeeper. Pode ser um nó líder ou seguidor. Depois que um cliente é conectado, o nó atribui um ID de sessão ao cliente específico e envia uma confirmação para o cliente. Se o cliente não obtiver uma confirmação, ele simplesmente tentará se conectar a outro nó no conjunto ZooKeeper. Uma vez conectado a um nó, o cliente enviará pulsações ao nó em um intervalo regular para garantir que a conexão não seja perdida.

• If a client wants to read a particular znode, envia um read requestpara o nó com o caminho znode e o nó retorna o znode solicitado obtendo-o de seu próprio banco de dados. Por esse motivo, as leituras são rápidas no conjunto ZooKeeper.

• If a client wants to store data in the ZooKeeper ensemble, ele envia o caminho znode e os dados para o servidor. O servidor conectado encaminhará a solicitação para o líder e, em seguida, o líder emitirá novamente a solicitação por escrito para todos os seguidores. Se apenas a maioria dos nós responder com êxito, a solicitação de gravação será bem-sucedida e um código de retorno bem-sucedido será enviado ao cliente. Caso contrário, a solicitação de gravação falhará. A maioria dos nós é chamada deQuorum.

Nós em um conjunto ZooKeeper

Vamos analisar o efeito de ter um número diferente de nós no conjunto ZooKeeper.

• Se tiver-mos a single node, o conjunto ZooKeeper falhará quando esse nó falhar. Isso contribui para o “Ponto Único de Falha” e não é recomendado em um ambiente de produção.

• Se tiver-mos two nodes e um nó falha, não temos maioria também, já que um em cada dois não é a maioria.

• Se tiver-mos three nodese um nó falha, temos maioria e, portanto, é o requisito mínimo. É obrigatório para um conjunto ZooKeeper ter pelo menos três nós em um ambiente de produção ativo.

• Se tiver-mos four nodese dois nós falham, ele falha novamente e é semelhante a ter três nós. O nó extra não tem nenhum propósito e, portanto, é melhor adicionar nós em números ímpares, por exemplo, 3, 5, 7.

Sabemos que um processo de gravação é caro do que um processo de leitura no conjunto ZooKeeper, uma vez que todos os nós precisam gravar os mesmos dados em seu banco de dados. Portanto, é melhor ter menos número de nós (3, 5 ou 7) do que ter um grande número de nós para um ambiente balanceado.

O diagrama a seguir descreve o ZooKeeper WorkFlow e a tabela subsequente explica seus diferentes componentes.

Componente	Descrição
Escreva	O processo de gravação é gerenciado pelo nó líder. O líder encaminha a solicitação de gravação para todos os znodes e espera por respostas dos znodes. Se metade dos znodes responder, o processo de gravação está concluído.
Ler	As leituras são realizadas internamente por um znode conectado específico, portanto, não há necessidade de interagir com o cluster.
Banco de dados replicado	Ele é usado para armazenar dados no zookeeper. Cada znode tem seu próprio banco de dados e cada znode tem os mesmos dados sempre com a ajuda da consistência.
Líder	Leader é o Znode responsável pelo processamento das solicitações de gravação.
Seguidor	Os seguidores recebem solicitações de gravação dos clientes e as encaminham ao znode líder.
Solicitar Processador	Presente apenas no nó líder. Ele controla as solicitações de gravação do nó seguidor.
Transmissões atômicas	Responsável por transmitir as mudanças do nó líder para os nós seguidores.