Características do tratador e seus cenários de utilização (fechaduras distribuídas e eleição do Mestre)

Características do tratador e seus cenários de utilização (fechaduras distribuídas e eleição do Mestre)

A estrutura de dados do zookeeper

O modelo de dados do Zookeeper é semelhante ao sistema de arquivos distribuído, que é uma estrutura de atributo hierárquica, conforme mostrado na figura. Ao contrário do sistema de arquivos, os dados do Zookeeper são armazenados de maneira estruturada e não refletem fisicamente arquivos e diretórios.

​ Cada nó na árvore do Zookeeper é chamado de Znode, e o Znode mantém uma informação de estado Stat, que inclui a hora e a versão das alterações de dados. E cada Znode pode definir um valor. O Zookeeper não precisa se comunicar com o banco de dados ou armazenar objetos de grande capacidade. Ele apenas gerencia e coordena os dados relacionados. Portanto, não é recomendado definir o tamanho dos dados de valor muito grande. Dados maiores trará maior sobrecarga de rede.

Os dados de cada nó no Zookeeper podem ser lidos e gravados. Ler significa obter os dados de valor no Znode especificado e escrever significa modificar os dados de valor no Znode especificado. Além disso, as regras de criação de nós são semelhantes às regras de criação de arquivos no sistema de arquivos. Deve ser criado hierarquicamente. Para dar um exemplo simples, se você precisar criar /node/node1/node1-1, deverá primeiro criar dois nós hierárquicos /node/node1.

Características do Zookeeper

Ao criar um Znode no Zookeeper, é necessário especificar o tipo de nó. Os tipos de nó são divididos em:

• Nó de persistência, os dados do nó serão persistidos no disco,
• Para nós temporários, o ciclo de vida do nó é consistente com o ciclo de declaração do cliente que criou o nó. Uma vez que a sessão do cliente terminar, o nó temporário criado pelo cliente também será excluído.
• Para nós ordenados, uma sequência crescente será adicionada após o nó criado, que é único no mesmo nível de nós pais. Deve-se observar que nós persistentes ou nós temporários também podem ser definidos como nós ordenados. Ou seja, nós persistentes ou nós ordenados temporários.

Após a versão 3.5.3, foram adicionados dois tipos de nós, nomeadamente

• Nó do contêiner, quando o último nó sob o nó do contêiner for excluído, o nó do contêiner será excluído.
• Para nós TTL, podemos definir um tempo de sobrevivência para nós persistentes ou nós ordenados persistentes.Se o nó não tiver nenhuma modificação e nenhum nó filho dentro do tempo de sobrevivência, ele será excluído automaticamente.

Deve-se observar que no mesmo diretório, o nome do nó deve ser único, assim como não podemos criar duas pastas com o mesmo nome no mesmo diretório.

mecanismo de observação

O Zookeeper fornece um mecanismo de assinatura/notificação para Znode, ou seja, quando o estado do nó Znode mudar ou o estado da conexão do cliente Zookeeper mudar, uma notificação de evento será acionada. Esse mecanismo fornece uma solução muito boa para que os chamadores de serviço percebam as mudanças nos provedores de serviço em tempo hábil durante o registro e a descoberta do serviço.

Na API java fornecida pelo Zookeeper, três mecanismos são fornecidos para registrar e monitorar Znodes, a saber:

• getData() é usado para obter as informações de valor do nó especificado e pode se registrar para monitoramento. Quando o nó monitorado é criado, modificado ou excluído, uma notificação de evento será acionada e respondida.
• getChildren() é usado para obter todos os nós filhos da lista especificada e permite o registro de ouvintes. Quando os nós filhos do nó ouvinte são criados, modificados ou excluídos, uma notificação de evento correspondente é acionada.
• exists(), usado para avaliar se o nó especificado existe e também pode registrar para monitorar o nó especificado. O tipo de monitoramento de tempo é o mesmo que getData().

O acionamento do evento Watcher é único. Por exemplo, o cliente registra o ouvinte por meio de getData('/node',true). Se os dados do nó /node forem modificados, o cliente receberá uma notificação de evento de modificação, mas o /node irá Quando ocorrer uma mudança, o cliente não pode receber o evento Watcher.Para resolver este problema, o cliente deve testar novamente o evento de registro no retorno de chamada do evento recebido.

Análise de Cenários de Aplicação Comuns

Com base nas características dos nós no Zookeeper, ele pode fornecer soluções para vários cenários de aplicativos.

bloqueio distribuído

Podemos usar as características do zookeeper para implementar bloqueios distribuídos. A essência dos bloqueios é a exclusividade, que é impedir que vários processos acessem um recurso compartilhado ao mesmo tempo.

Essa operação pode ser realizada usando as características do nó temporário e a exclusividade do nó ao mesmo tempo.

• O processo de aquisição de um bloqueio

  Ao adquirir um bloqueio exclusivo, todos os clientes podem criar um nó temporário /lock no nó /Exclusive_Locks no servidor Zookeeper. Com base na exclusividade dos nós no mesmo nível, o Zookeeper garantirá que apenas um cliente entre todos os clientes possa ser criado com sucesso. O cliente criado com sucesso obtém um bloqueio exclusivo. Os clientes que não obtêm o bloqueio precisam monitorar os nós filhos sob o /Exclusive_Locks através do mecanismo Watcher. change event.

• O processo de liberar o bloqueio

  No processo de aquisição do bloqueio, definimos o nó de bloqueio/bloqueio como um nó temporário.De acordo com as características do nó temporário, a liberação do bloqueio será acionada nos dois casos a seguir.

  • O cliente que adquiriu o bloqueio se desconectou do servidor devido a uma exceção. Com base no nó temporário, o nó /lock será excluído automaticamente.
  • Após o cliente que adquire o bloqueio executar a lógica de negócios, ele exclui ativamente o nó /lock criado.

  Quando o nó /lock for excluído, o Zookeeper notificará outros clientes que ouviram as alterações do subnó /Exclusive_Locks. Após receber a notificação, esses clientes iniciam a operação de criação de nós /lock novamente para obter bloqueios exclusivos.

Eleição Principal

A eleição de mestre é um cenário muito comum em um sistema distribuído. Em uma arquitetura distribuída, para garantir a disponibilidade dos serviços, geralmente é adotado o modo cluster, ou seja, quando uma das máquinas fica inativa, outros nós do cluster assumem do nó com falha para continuar o trabalho. Nesse cenário, você precisa eleger um nó do cluster como o nó mestre e os nós restantes ficam em espera como nós de backup. Quando o nó mestre original falha, é necessário eleger um nó de outros nós de backup no cluster como o nó mestre para continuar a fornecer serviços.

• O mesmo nó não pode criar repetidamente um nó existente. Isso é um pouco semelhante ao cenário de implementação de bloqueios distribuídos. Na verdade, o mesmo é verdadeiro para o cenário de eleição do Mestre. Assumindo que existem 3 nós no cluster e o mestre precisa ser eleito, então esses três nós vão para o servidor Zookeeper para criar um nó temporário/mestre-eleição ao mesmo tempo. Devido às características do nó, apenas um cliente será criado com sucesso e o Watcher será registrado para este nó. O evento é usado para monitorar se a máquina Master atual está ativa. Uma vez que o Master está "pendurado", ou seja, o nó /master-election é excluído, outros clientes reiniciarão a operação de eleição do Master.

• É realizado usando as características dos nós ordenados temporários. Todos os clientes que participam da eleição criam um nó ordenado temporário sob o nó /master do servidor Zookeeper. O nó com o menor número representa o Mestre. Os nós subseqüentes podem monitorar o tempo de exclusão do nó anterior para acionar a reeleição.

Exemplo: três nós client01, client02 e client03 vão para o nó /master do Zookeeper Server para criar nós temporários ordenados, client01, o nó com o menor número, representa o nó Master, e três nós client02 e client03 vão para o /master node do Zookeeper Server para criar nodes temporários e válidos Node, client01 cria /client01-0000000001, client-02 cria /client02-0000000003, client-03 cria /client03-0000000002, o node com o menor número client01 representa o master node, client02 e client03 monitorarão respectivamente o nó com um número menor que o seu próprio através do mecanismo Watcher a node. Por exemplo, client02 monitora /client03-0000000002 e client03 monitora /client01-0000000001. Se o menor nó for excluído, client03 será eleito como mestre.

Princípio de implementação do Centro de Registro de Zookeeper

Após o registro do serviço Dubbo no Zookeeper, você pode ver a estrutura em árvore mostrada na figura abaixo no servidor Zookeeper.

Quando o serviço Dubbo for iniciado, ele levará a URL do serviço atual criado /dubbbo/com.scmpe.dubbo.IHelloService/providesno diretório , onde com.scmpe.dubbo.IHelloServiceé o nome do caminho completo da interface que publica o serviço, e os provedores indicam o tipo de provedor de serviço, indicando o dubbo://ip:port tipo de protocolo e o endereço de acesso da publicação do serviço. Entre eles, o URL é um nó temporário e os demais são todos nós persistentes. Por que a URL usa um nó temporário aqui, porque se o servidor que registrou o nó ficar offline, o endereço da URL do servidor será removido do servidor Zookeeper.

Quando o consumidor do serviço Dubbo iniciar, ele registrará /dubbbo/com.scmpe.dubbo.IHelloService/provideso Watcher para monitorar os sub-nós sob o nó, para que ele possa perceber a alteração do nó do provedor de serviços off-line e off-line e impedir que a solicitação seja enviada ao servidor off-line para causar falha de acesso. Ao mesmo tempo, os consumidores de serviço escreverão seus próprios URLs /dubbbo/com.scmpe.dubbo.IHelloService/cosumers abaixo . O objetivo disso é ver quais serviços um determinado serviço Dubbo está sendo chamado na plataforma de monitoramento; mais importante, se os consumidores de serviços Dubbo precisarem chamar o serviço IHelloService, então ele primeiro volta ao /dubbbo/com.scmpe.dubbo.IHelloService/provides caminho para obter a lista de URLs do provedor de todos os serviços e, em seguida, calcula um endereço para acesso remoto por meio do algoritmo de balanceamento de carga.

​ No geral, as funções de registro de serviço e percepção dinâmica usam nós temporários, nós persistentes, observadores, etc. no Zookeeper. Olhando novamente para os cenários de aplicativos do Zookeeper analisados ​​anteriormente, podemos descobrir que quase todos os cenários são baseados neles. . Além disso, deve ser mencionado que o Dubbo também pode implementar as seguintes funções para diferentes situações.

• Com base nas características do nó temporário, quando o provedor de serviços cair ou ficar offline, a central de registro excluirá automaticamente as informações do provedor de serviços
• Quando o centro de registro é reiniciado, o Dubbo pode responder automaticamente aos dados de registro e solicitações de assinatura.
• Para garantir a segurança das operações do nó, o Zookeeper fornece controle de permissão ACL e, no Dubbo, as informações de autenticação dos nós podem dubbo.registry.username/dubbo.registry.password ser definidas por meio de .
• O nó raiz padrão do registro é /dubbo.Se precisar definir diferentes nós raiz para diferentes ambientes, você pode usar dubbo.registry.group para modificar o nome do nó raiz.