Zookeeper - Fundamentos

Antes de nos aprofundarmos no funcionamento do ZooKeeper, vamos dar uma olhada nos conceitos fundamentais do ZooKeeper. Discutiremos os seguintes tópicos neste capítulo -

Architecture
Namespace hierárquico
Session
Watches

Arquitetura do ZooKeeper

Dê uma olhada no diagrama a seguir. Ele descreve a “Arquitetura Cliente-Servidor” do ZooKeeper.

Cada um dos componentes que fazem parte da arquitetura do ZooKeeper foi explicado na tabela a seguir.

Parte	Descrição
Cliente	Os clientes, um dos nós em nosso cluster de aplicativos distribuídos, acessam informações do servidor. Por um determinado intervalo de tempo, cada cliente envia uma mensagem ao servidor para que ele saiba que o cliente está ativo. Da mesma forma, o servidor envia uma confirmação quando um cliente se conecta. Se não houver resposta do servidor conectado, o cliente redireciona automaticamente a mensagem para outro servidor.
Servidor	O servidor, um dos nós em nosso conjunto ZooKeeper, fornece todos os serviços aos clientes. Reconhece o cliente para informar que o servidor está ativo.
Conjunto	Grupo de servidores ZooKeeper. O número mínimo de nós necessários para formar um conjunto é 3.
Líder	Nó do servidor que executa a recuperação automática se algum dos nós conectados falhar. Os líderes são eleitos no início do serviço.
Seguidor	Nó do servidor que segue as instruções do líder.

Namespace hierárquico

O diagrama a seguir descreve a estrutura em árvore do sistema de arquivos ZooKeeper usado para representação de memória. O nó ZooKeeper é referido comoznode. Cada znode é identificado por um nome e separado por uma sequência de caminho (/).

No diagrama, primeiro você tem uma raiz znodeseparado por "/". Na raiz, você tem dois namespaces lógicosconfig e workers.
o config namespace é usado para gerenciamento de configuração centralizado e o workers namespace é usado para nomenclatura.
Debaixo confignamespace, cada znode pode armazenar até 1 MB de dados. Isso é semelhante ao sistema de arquivos UNIX, exceto que o znode pai também pode armazenar dados. O principal objetivo dessa estrutura é armazenar dados sincronizados e descrever os metadados do znode. Esta estrutura é chamada deZooKeeper Data Model.

Cada znode no modelo de dados ZooKeeper mantém um statestrutura. Uma estatística simplesmente fornece ometadatade um znode. Consiste em número de versão, lista de controle de ação (ACL), carimbo de data / hora e comprimento de dados.

Version number- Cada znode tem um número de versão, o que significa que toda vez que os dados associados ao znode mudam, seu número de versão correspondente também aumenta. O uso do número da versão é importante quando vários clientes zookeeper estão tentando realizar operações no mesmo znode.
Action Control List (ACL)- ACL é basicamente um mecanismo de autenticação para acessar o znode. Ele governa todas as operações de leitura e gravação do znode.
Timestamp- O carimbo de data / hora representa o tempo decorrido desde a criação e modificação do znode. Geralmente é representado em milissegundos. O ZooKeeper identifica todas as alterações nos znodes de “ID de transação” (zxid).Zxid é único e mantém o tempo de cada transação para que você possa identificar facilmente o tempo decorrido de uma solicitação a outra.
Data length- A quantidade total de dados armazenados em um znode é o comprimento dos dados. Você pode armazenar no máximo 1 MB de dados.

Tipos de Znodes

Znodes são categorizados como persistência, sequencial e efêmero.

Persistence znode- O znode de persistência está ativo mesmo depois que o cliente, que criou aquele znode específico, é desconectado. Por padrão, todos os znodes são persistentes, a menos que especificado de outra forma.
Ephemeral znode- Os znodes efêmeros ficam ativos até que o cliente esteja ativo. Quando um cliente é desconectado do conjunto ZooKeeper, os znodes efêmeros são excluídos automaticamente. Por esse motivo, apenas znodes efêmeros não podem ter mais filhos. Se um znode efêmero for excluído, o próximo nó adequado preencherá sua posição. Os znodes efêmeros desempenham um papel importante na eleição do líder.
Sequential znode- Os znodes sequenciais podem ser persistentes ou efêmeros. Quando um novo znode é criado como um znode sequencial, o ZooKeeper define o caminho do znode anexando um número de sequência de 10 dígitos ao nome original. Por exemplo, se um znode com caminho/myapp é criado como um znode sequencial, o ZooKeeper mudará o caminho para /myapp0000000001e defina o próximo número de sequência como 0000000002. Se dois znodes sequenciais forem criados simultaneamente, o ZooKeeper nunca usará o mesmo número para cada znode. Os znodes sequenciais desempenham um papel importante no bloqueio e na sincronização.

Sessões

As sessões são muito importantes para o funcionamento do ZooKeeper. As solicitações em uma sessão são executadas na ordem FIFO. Depois que um cliente se conecta a um servidor, a sessão será estabelecida e umsession id é atribuído ao cliente.

O cliente envia heartbeatsem um determinado intervalo de tempo para manter a sessão válida. Se o conjunto ZooKeeper não receber pulsações de um cliente por mais do que o período (tempo limite da sessão) especificado no início do serviço, ele decidirá que o cliente morreu.

Os tempos limite de sessão são geralmente representados em milissegundos. Quando uma sessão termina por qualquer motivo, os znodes efêmeros criados durante essa sessão também são excluídos.

Relógios

Os relógios são um mecanismo simples para o cliente receber notificações sobre as mudanças no conjunto ZooKeeper. Os clientes podem definir relógios enquanto lêem um znode específico. Os relógios enviam uma notificação ao cliente registrado para qualquer alteração do znode (no qual o cliente se registra).

Mudanças de znode são modificações de dados associados ao znode ou mudanças nos filhos do znode. Os relógios são acionados apenas uma vez. Se um cliente deseja uma notificação novamente, isso deve ser feito por meio de outra operação de leitura. Quando uma sessão de conexão expira, o cliente é desconectado do servidor e os relógios associados também são removidos.