Zookeeper é um subprojeto do Hadoop e, embora derive do Hadoop, percebi que o Zookeeper está usando cada vez mais frameworks distribuídos fora do Hadoop. Hoje quero falar sobre zookeeper; este artigo não vai falar sobre como usar o zookeeper, mas quais são as aplicações práticas do zookeeper, quais tipos de aplicações podem beneficiar do zookeeper e, por fim, falar sobre qual papel o zookeeper pode desempenhar na arquitetura distribuída de sites.
O Zookeeper é um sistema de coordenação altamente confiável para grandes sistemas distribuídos. A partir dessa definição, sabemos que o cuidador de zoológico é um sistema coordenado que atua em sistemas distribuídos. Por que sistemas distribuídos precisam de um sistema de coordenação? Os motivos são os seguintes:
Desenvolver um sistema distribuído é algo muito difícil, e essa dificuldade se reflete principalmente na "falha parcial" do sistema distribuído. "Falha parcial" refere-se à transmissão de informações entre dois nós da rede; se a rede falhar, o remetente não pode saber se o receptor recebeu a mensagem, e a causa dessa falha é complexa, o receptor pode ou não ter recebido a mensagem antes do erro da rede, ou o processo do receptor está morto. A única forma do remetente obter a imagem real é reconectar ao receptor e perguntar ao receptor por que o erro ocorreu, que é o problema da "falha parcial" no desenvolvimento de sistemas distribuídos.
Zookeeper é a estrutura para resolver a "falha parcial" dos sistemas distribuídos. O Zookeeper não permite que sistemas distribuídos evitem problemas de "falha parcial", mas permite que sistemas distribuídos lidam corretamente com esses problemas ao enfrentar falhas parciais, para que sistemas distribuídos possam operar normalmente.
Vamos falar sobre o uso prático do tratador de zoológico:
Cenário 1: Existe um grupo de servidores que fornecem um certo serviço ao cliente (por exemplo, o lado do servidor do site distribuído que criei anteriormente é um cluster composto por quatro servidores para fornecer serviços ao cluster front-end), e esperamos que o cliente possa encontrar um servidor no cluster de servidores toda vez que o cliente solicitar, para que o servidor possa fornecer ao cliente os serviços necessários pelo cliente. Para esse cenário, precisamos ter uma lista de servidores em nosso programa, da qual lemos a lista de servidores toda vez que o cliente solicitar. Então, essa sublista obviamente não pode ser armazenada em um único servidor de nó, caso contrário o nó desligará e todo o cluster falhará, e esperamos que essa lista esteja altamente disponível nesse momento. Se um servidor na lista de armazenamento estiver quebrado, outros servidores podem imediatamente substituir o servidor quebrado, e o servidor quebrado pode ser removido da lista, para que o servidor falhado possa se retirar da operação de todo o cluster, e todas essas operações não serão operadas pelo servidor falhado, mas pelo servidor normal no cluster. Esta é uma estrutura de dados distribuída ativa que pode modificar ativamente o estado dos itens de dados quando condições externas mudam. O framework Zookeeper oferece esse serviço. O nome desse serviço é: Serviço Unificado de Nomenclatura, que é muito semelhante ao serviço JNDI em javaEE.
Cenário 2: Serviço de fechadura distribuída. Quando um sistema distribuído manipula dados, como ler dados, analisar dados e, finalmente, modificar dados. No sistema distribuído, essas operações podem ser dispersas para diferentes nós no cluster, então há um problema de consistência no processo de operação dos dados; se for inconsistente, obteremos um resultado errado da operação; em um único programa de processo, o problema da consistência é fácil de resolver, mas é mais difícil alcançar o sistema distribuído, porque as operações dos diferentes servidores no sistema distribuído estão em processos independentes, e os resultados intermediários e processos da operação devem ser transmitidos pela rede. Assim, fica muito mais difícil alcançar consistência na operação dos dados. O Zookeeper oferece um serviço de bloqueio que resolve esse problema, permitindo garantir a consistência das operações de dados ao realizar operações distribuídas.
Cenário 3: Gerenciamento de configuração. Em um sistema distribuído, implantamos uma aplicação de serviço para n servidores separadamente, e os arquivos de configuração desses servidores são os mesmos (por exemplo, no framework de sites distribuídos que projetei, há 4 servidores no lado do servidor, os programas nos 4 servidores são os mesmos e os arquivos de configuração são os mesmos), se as opções de configuração dos arquivos de configuração mudarem, então temos que mudar esses arquivos um a um, se precisarmos mudar os servidores são relativamente pequenos, essas operações não são muito problemáticas, Se tivermos um grande número de servidores distribuídos, como o cluster Hadoop de uma grande empresa de Internet com milhares de servidores, então mudar as opções de configuração pode ser algo problemático e perigoso. Neste momento, o zookeeper pode ser útil, podemos usar o zookeeper como uma memória de configuração altamente disponível, entregar isso para o zookeeper para gerenciamento, copiamos o arquivo de configuração do cluster para um nó do sistema de arquivos do zookeeper e então usamos o zookeeper para monitorar o status do arquivo de configuração em todos os sistemas distribuídos, assim que se descobre que o arquivo de configuração mudou, Cada servidor receberá uma notificação do Zookeeper para sincronizar os arquivos de configuração no Zookeeper, e o serviço Zookeeper também garantirá que a operação de sincronização seja atômica para garantir que o arquivo de configuração de cada servidor seja atualizado corretamente.
Cenário 4: Fornecer funções de reparo de falhas para sistemas distribuídos. O gerenciamento de clusters é difícil, e adicionar o serviço de tratador ao sistema distribuído facilita nosso gerenciamento do cluster. A coisa mais problemática no gerenciamento de cluster é o gerenciamento de falhas de nós; o zookeeper pode permitir que o cluster selecione um nó saudável como mestre, o nó mestre saberá o status atual de saúde de cada servidor no cluster; quando um nó falha, o mestre notificará os outros servidores do cluster para redistribuir as tarefas de computação de diferentes nós. O Zookeeper não só pode encontrar falhas, mas também analisar o servidor defeituoso, ver que tipo de falha é o servidor de falhas, se a falha pode ser reparada, o Zookeeper pode corrigir automaticamente ou informar ao administrador do sistema o motivo do erro, para que o administrador possa rapidamente localizar o problema e reparar a falha do nó. Você ainda pode ter uma dúvida: o que devo fazer se o mestre estiver com defeito? O Zookeeper também leva isso em consideração, o zookeeper possui um "algoritmo interno para eleger líderes", os mestres podem ser selecionados dinamicamente e, quando o mestre falha, o zookeeper pode imediatamente selecionar um novo mestre para gerenciar o cluster.
Vamos falar sobre as características do tratador de zoológico:
ZooKeeper é um sistema de arquivos simplificado. Isso é um pouco parecido com o Hadoop, mas o sistema de arquivos ZooKeeper gerencia arquivos pequenos, enquanto o Hadoop gerencia arquivos muito grandes.
O Zookeeper oferece uma riqueza de "artefatos" que permitem que muitas operações coordenem estruturas de dados e protocolos. Por exemplo: filas distribuídas, bloqueios distribuídos e o algoritmo de "eleição de líder" de um grupo de nós no mesmo nível.
O ZooKeeper é altamente disponível, sua própria estabilidade é bastante boa, clusters distribuídos podem depender da gestão dos clusters Zookeeper, e o ZooKeeper é usado para evitar o problema da falha pontual única dos sistemas distribuídos.
O Zookeeper adota um modo de interação vagamente acoplado. Isso é mais evidente no fato de que o zookeeper fornece locks distribuídos, que podem ser usados como mecanismo de marcação para permitir que processos participantes descubram e interajam entre si sem conhecer os outros processos (ou a rede), e as partes participantes nem precisam existir ao mesmo tempo, desde que deixem uma mensagem no zookeeper e, após o término do processo, outro processo possa ler essa mensagem, desacoplando assim a relação entre nós.
O ZooKeeper fornece um repositório compartilhado para o cluster, a partir do qual o cluster pode ler e gravar informações compartilhadas centralmente, evitando a programação de operações compartilhadas para cada nó e reduzindo a dificuldade de desenvolvimento dos sistemas distribuídos.
O Zookeeper é principalmente responsável por armazenar e gerenciar os dados que todos valorizam, e então aceitar o registro dos observadores; uma vez que o status desses dados mude, o Zookeeper será responsável por notificar aqueles observadores que se registraram no Zookeeper para responder adequadamente, de modo a alcançar um modo de gerenciamento mestre/escravo semelhante ao do cluster.
Pode-se ver que o Zookeeper é muito propício ao desenvolvimento de sistemas distribuídos, o que pode tornar os sistemas distribuídos mais robustos e eficientes.
Não faz muito tempo, participei do grupo de interesse Hadoop do departamento, instalei hadoop, mapreduce, Hive e Hbase no ambiente de teste, e instalei o Zookeeper com antecedência ao instalar o hbase. O Zookeeper pode fornecer serviços, então mais da metade dos 3 são 2, e mais da metade dos 4 também são dois, então instalar três servidores pode alcançar o efeito de 4 servidores. No processo de aprender Hadoop, sinto que o Zookeeper é o subprojeto mais difícil de entender, o motivo não é que ele seja tecnicamente responsável, mas que sua direção de aplicação me confunde, então meu primeiro artigo sobre tecnologia Hadoop começa com Zookeeper e não fala sobre implementação técnica específica, mas pelos cenários de aplicação do Zookeeper, entendo o campo da aplicação do Zookeeper, acho que aprender o Zookeeper será mais eficaz com metade do esforço.
O motivo pelo qual quero falar sobre o zookeeper hoje é para complementar o framework de sites distribuídos no meu artigo anterior. Embora eu tenha projetado a arquitetura do site para ser uma estrutura distribuída, também criei um mecanismo simples de tratamento de falhas, como o mecanismo heartbeat, mas ainda não há como resolver o ponto único de falha do cluster; se um servidor estiver quebrado, o cliente tentará se conectar a esse servidor, resultando no bloqueio de algumas solicitações e também no desperdício de recursos do servidor. No entanto, não quero modificar meu framework no momento, porque sempre sinto que adicionar o serviço zookeeper aos serviços existentes vai afetar a eficiência do site. Felizmente, nosso departamento também encontrou esse problema: desenvolverá uma estrutura poderosa de chamadas remotas, separará o gerenciamento de cluster e a gestão de comunicação, e fornecerá serviços eficientes e disponíveis centralmente.
Transferido de ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Publicado em 18/07/2017 14:19:01
|
|
|
