Aprendizagem de protocolo distribuído - uma compreensão completa de Multi-Paxos

Prefácio

  Artigo "Aprendizado de protocolo distribuído - uma compreensão completa do algoritmo de consenso do Paxos básico" Após ler este artigo, você deve entender que o Paxos básico só pode chegar a um consenso sobre um único valor (valor). Quando é necessário chegar a um consenso sobre uma série de valores, o Basic Paxos não funciona.

O que é Multi-Paxos

 Multi-Paxos é apenas uma ideia, não um algoritmo. O algoritmo Multi-Paxos é um termo coletivo. Refere-se a um algoritmo de consenso baseado na ideia de Multi-Paxos para implementar uma série de valores por meio de múltiplas instâncias de Basic Paxos.
 O Basic Paxos obtém consenso por meio de um commit de duas fases. No primeiro estágio, o estágio de preparação, apenas os proponentes que receberam a maioria das respostas preparadas podem iniciar a solicitação de aceitação e entrar no estágio de aceitação. Conforme mostrado na figura abaixo:

 Agora, se você executar diretamente a instância básica de paxos várias vezes para chegar a um consenso sobre uma série de valores, haverá os seguintes problemas:

1. Quando vários proponentes enviam propostas ao mesmo tempo, pode haver conflitos nos números das propostas, fazendo com que nenhum proponente receba muitas respostas de preparação durante a fase de preparação. Fazer com que a negociação fracasse e precise renegociar . Por exemplo, em um cluster com 3 nós, se 2 nós agem como proponentes para fazer propostas ao mesmo tempo, pode acontecer que a preparação falhe porque nenhum proponente recebe a maioria das respostas, e a renegociação é necessária.
2. A fase de preparação e a fase de aceitação são, na verdade, duas rodadas de comunicação RPC. No caso de muitas mensagens de ida e volta, isso pode causar muitos atrasos.

 Para resolver os problemas acima, considere a introdução de um novo nó de função, o líder (Líder), como o único proponente, para que não haja problema de conflito de envio de propostas.

 A eleição de líderes precisa ser realizada por você mesmo. A seguir, devemos considerar como otimizar o Basic Paxos. Geralmente, devemos pular a fase de preparação e ir diretamente para a fase de aceitação. Desta forma, o nó do líder, o comando fica atualizado, não sendo mais necessário preparar uma solicitação para descobrir o movimento passado pela maioria dos nós anteriores. O líder pode especificar independentemente o valor do movimento. Desta forma, você pode entrar diretamente na fase de aceitação.

 Como pode ser visto na figura acima, depois que Multi-Paxos introduz o nó líder, não há conflito de proposta porque há apenas um proponente para o nó líder. Quando o nó líder entra em um estado estável, ele pode entrar diretamente na fase de aceitação, o que reduz muito o número de mensagens de ida e volta, melhorando assim o desempenho e reduzindo a latência. Vamos analisar como o Multi-Paxos do Chubby é implementado em detalhes.

Como Chubby implementa Multi-Paxos

 O Google Chubby é um serviço de bloqueio de sistema distribuído fracamente acoplado. Tanto o GFS quanto o Big-Table o usam para resolver uma série de problemas relacionados ao bloqueio distribuído, como colaboração distribuída, escolha de nó mestre e armazenamento de metadados. Chubby fornece um serviço de bloqueio distribuído de granulação grossa. Toda a sua estrutura de sistema é composta principalmente por servidor e cliente, o cliente se comunica com o servidor através de chamadas RPC. Sua consistência subjacente é baseada no Paxos.
  O mestre em Chubby é o único proponente, para que não haja uma situação em que vários proponentes apresentem propostas ao mesmo tempo e causem conflitos de propostas.
  Então, como o nó mestre é gerado? Em uma célula Chubby (célula Chubby), o servidor de réplica geralmente usa o protocolo Basix Paxos para votar no mestre. Depois que o mestre é eleito, o Chubby não usará mais outros servidores como nós mestre por um período. Esse período é chamado de Lease. Durante a operação, o nó mestre irá estender o período de aluguel renovando continuamente o aluguel. Por exemplo, o mesmo nó serve como nó mestre por vários dias. Se o nó mestre falhar, outros nós iniciarão uma nova rodada de votação para eleger um novo nó mestre após a expiração do aluguel. O novo nó mestre executará a nova concessão.
 O cliente do Chubby primeiro solicita uma lista de todos os servidores Chubby do DNS que registra a lista de máquinas do servidor Chubby e, em seguida, inicia uma solicitação, um por um, para perguntar se o servidor é o mestre. Nesse processo de consulta, esses servidores não-mestre Envie o logotipo do servidor do mestre atual para o cliente, para que o cliente possa localizar rapidamente o servidor mestre.
　  Para obter uma consistência forte, desde que o servidor mestre esteja funcionando normalmente, o cliente enviará todas as solicitações ao servidor mestre. Todas as solicitações de leitura e gravação são tratadas pelo mestre.

Pedido de escrita

  Quando o mestre recebe uma solicitação de gravação do cliente, como proponente, ele usará o protocolo Paxos Básico para transmitir a solicitação de gravação para todos os nós e, após mais da metade dos nós aceitarem a solicitação de gravação, ele responderá ao cliente com uma solicitação de gravação bem-sucedida.

Leia o pedido

  Quando o mestre recebe a solicitação de leitura, o nó mestre só precisa consultar os dados locais e, em seguida, devolvê-los ao cliente.
  Para reduzir a pressão no servidor causada por solicitações de leitura frequentes do cliente e do servidor, o conteúdo do arquivo e os metadados serão armazenados em cache no cliente. Embora o desempenho seja aprimorado por meio do armazenamento em cache, ele também traz problemas de consistência.O Chubby adota um mecanismo de aluguel para garantir a consistência dos dados. O cache de cada cliente está associado ao aluguel mestre. Pode-se entender que o cache do cliente tem um aluguel. Quando o aluguel expira, o cliente precisa renovar o aluguel com o mestre para continuar a manter a eficácia do cache.