MIT 6.824 Aula 6: Raft e Tolerância a Falhas, Parte 1

[0:01] Tudo bem, vamos começar. Mm-hmm. Hoje, e de fato hoje e amanhã, vou falar sobre o Raft. Hum, tanto porque espero que seja útil para vocês na implementação dos laboratórios. E também porque, você sabe, é apenas um estudo de caso nos detalhes de como fazer a replicação de máquina de estados corretamente. Então, como introdução ao problema, vocês podem ter notado um padrão nos sistemas de tolerância a falhas que examinamos até agora.

[0:35] Hum, Um é que o MapReduce replica a computação, mas A replicação é controlada, toda a computação é controlada por um único mestre. Hum, Outro exemplo que gostaria de chamar a atenção é que o GFS replica dados, certo, como esse esquema de backup primário para replicar o conteúdo real dos arquivos, mas Ele depende de um único mestre. para escolher quem é o primário para cada pedaço de dados. Outro exemplo, o VMware FT replica a computação, certo, em uma máquina virtual primária e uma máquina virtual de backup. Mas para descobrir o que fazer em seguida, se uma delas parece falhar, ele depende de um único servidor de teste e configuração.

[1:20] para ajudá-lo a escolher, para ajudá-lo a garantir que exatamente um dos primários ou do backup assuma se houver algum tipo de falha. Então, em todos esses três casos, Claro, havia um sistema de replicação, mas meio escondido em um canto no sistema de replicação, havia algum esquema em que uma única entidade era necessária para tomar uma decisão crítica sobre. quem era o primário nos casos que nos importam. Então, vou começar com o primeiro. uma coisa muito boa sobre ter uma única entidade decidir quem será o primário?

[1:52] é que ela não pode discordar de si mesma. Há apenas uma dela, toma alguma decisão, essa é a decisão que ela tomou. Hum, Mas a coisa ruim sobre ter uma única entidade decidir, tipo, quem é o primário, é que ela própria é um ponto único de falha. E então vocês podem ver esses sistemas que examinamos como que... empurrando o verdadeiro coração da maquinaria de tolerância a falhas para um cantinho. Ou seja, a única entidade que decide quem será o primário. se houver uma falha. Agora, Tudo isso é sobre como evitar o cérebro dividido. A razão pela qual temos que ter, ter que ser extremamente cuidadosos ao tomar a decisão sobre quem deve ser o primário, se houver uma falha, é que caso contrário corremos o risco de cérebro dividido.

[2:35] Hum, E só... deixar esse ponto super claro, vou apenas lembrá-los. qual é o problema e por que é um problema sério. Então, suponhamos, por exemplo, que nós, Hum, Queremos construir um servidor de teste e configuração replicado. Ou seja, estamos preocupados com o fato de que o VMware FT depende desse servidor de teste e configuração para-- escolher quem é o primário, então vamos construir um servidor de teste e configuração replicado. E vou fazer isso, vai ser quebrado, é apenas uma ilustração de por que é difícil acertar o problema do cérebro dividido. Então, vocês sabem, vamos imaginar que temos uma rede, e talvez dois servidores, que deveriam ser réplicas do nosso serviço de Teste e configuração conectados e, você sabe, talvez dois clientes que precisam saber quem é o primário agora? ou na verdade, talvez esses clientes neste caso sejam um O primário e o backup.

[3:30] hum, no VMware FT. Então, Se é um serviço de teste e configuração, então ambos esses bancos de dados, ambos esses servidores começam com seu estado, ou seja, o estado deste teste e configuração sendo zero. a única operação que seus clientes podem enviar é a operação de teste e configuração que deveria definir o do serviço replicado para um, então deveria definir ambas as cópias. e então retornar o valor antigo. Então ele essencialmente age como um tipo de servidor de bloqueio simplificado. Hum, Obrigado.

[4:01] OK. A situação problema? O que nos preocupa, o cérebro dividido surge automaticamente. quando um cliente pode falar com um dos servidores mas não pode falar com o outro. Então estamos imaginando que quando os clientes enviam uma solicitação, eles a enviam para ambos. Hum, vou apenas assumir isso agora, quase não importa. Então vamos assumir que o protocolo é que o cliente deve enviar ordinariamente qualquer solicitação para ambos os servidores, E De alguma forma, precisamos pensar sobre o que o cliente deve fazer se um dos servidores não responder.

[4:32] ou o que o sistema deve fazer se um dos servidores parecer não responder. Hum, Obrigado. Então vamos imaginar agora que o cliente um pode contatar o servidor um mas não o servidor dois. Como o sistema deve reagir? Uma possibilidade é que pensemos, bem, você sabe, caramba, Certamente não queremos apenas falar com o cliente para o servidor um, porque isso deixaria a segunda réplica inconsistente se definíssemos este valor para um, mas não definíssemos também este valor para um. Então talvez a regra deva ser que um cliente sempre precise falar com ambas as réplicas. para ambos os servidores. para qualquer operação e não deveria ser permitido falar apenas com um deles.

[5:05] Então por que essa é a resposta errada? Suponhamos que a regra seja, oh, em nosso sistema replicado, o cliente sempre precisa Falar com ambas as réplicas. para fazer progresso. Obrigado. Isso não é tolerante a falhas de jeito nenhum. Na verdade, é pior. É pior. do que falar com um único servidor porque agora o sistema tem um problema se qualquer um desses servidores falhar ou se você não puder falar com ele. Pelo menos com um servidor não replicado, você depende apenas de um servidor. Mas aqui temos que ambos os servidores estejam vivos. Se exigirmos que o cliente fale com ambos os servidores então. Ambos os servidores têm que estar vivos. Então não podemos de forma alguma exigir que o cliente realmente, você sabe, espere que ambos os servidores respondam.

[5:48] Se não temos tolerância a falhas, precisamos que ele possa prosseguir. Então outra resposta óbvia é que, Se o cliente não pode falar com ambos, bem, ele apenas fala com aquele com quem pode falar e conclui que o outro está morto. Então por que isso também não é a resposta certa? O cenário preocupante é se o outro servidor estiver na verdade vivo. Então suponha que o problema real que estamos encontrando não seja que o servidor falhou, o que seria bom para nós, mas o problema muito pior de que algo deu errado com o cabo de rede. E que este cliente pode falar com, o cliente um pode falar com o servidor um mas não com o servidor dois.

[6:27] E talvez haja algum outro cliente por aí que possa falar com o servidor dois mas não com o servidor um. Então, Se fizermos a regra, de que se um cliente não pode falar com ambos os servidores, tudo bem para ser tolerante a falhas, que ele apenas falou com um, então o que-- inevitavelmente vai acontecer. disse, este cabo vai quebrar, assim Cortando a rede ao meio. Vou-- enviar uma solicitação de teste e configuração para o servidor um, O servidor um definirá seu estado para um. Retornará o valor anterior de 0 para o cliente 1. E então isso significa que o cliente 1 pensará que tem o bloqueio.

[7:00] e se for um VMware FT, o servidor pensará que pode ser o primário de assumir. Mas esta réplica ainda tem zero nela. Certo, então agora se o cliente dois também enviar uma solicitação de teste e configuração, para Você sabe, nós-- tenta enviá-las para ambos, vê que o servidor um parece estar inativo, segue a regra que diz, bem, você apenas envia para o servidor com quem pode falar, então ele também pensará que Hum. adquiriu, o cliente dois também pensará que adquiriu o bloqueio. E então agora, Você sabe, se estivéssemos imaginando que este servidor de teste e configuração seria usado com o VMware FT, temos, você sabe, Ambos.

[7:31] uh, réplica, ambas essas máquinas VMware, uh, eu acho que elas poderiam ser primárias por si mesmas. Hum, sem consultar o outro servidor. Então isso é uma falha completa. Então com esta configuração e dois servidores, Parecia que tínhamos isso, nós apenas tínhamos que escolher, ou você espera por ambos e não é tolerante a falhas, ou Você espera por apenas um e não é correto. E a versão não correta é frequentemente chamada de cérebro dividido. Então. Todos veem isso? Obrigado.

[8:03] Mm-mm. Bem. Hum... Então foi basicamente onde as coisas estavam. até o final dos anos 80. E Mas as pessoas queriam construir Sistemas replicados. os computadores que controlam centrais telefônicas, ou os computadores que administravam bancos, você sabe. Esses lugares estão dispostos a gastar uma quantia enorme de dinheiro para ter um serviço confiável, e então eles replicavam, eles construíam sistemas replicados, e a maneira como eles lidavam A maneira como eles-- tinham replicação mas tentavam excluir o cérebro dividido. É um par de técnicas. Uma é Eles construíam uma rede que não podia falhar.

[8:44] E então, geralmente o que isso significa, e de fato vocês usam redes que essencialmente não podem falhar o tempo todo. os fios dentro do seu laptop, você sabe, conectando a CPU à DRAM são efetivamente uma rede que não pode falhar. entre a-- entre sua CPU e a DRAM. Então, você sabe, com suposições razoáveis e muito dinheiro, e aquilo, você sabe, meio que uma situação física cuidadosamente controlada, tipo você não quer ter um cabo serpenteando pelo chão que alguém possa pisar, sabe, tem que ser uma configuração fisicamente bem projetada. Com uma rede que não pode falhar, você pode descartar o cérebro dividido. É meio que uma suposição, mas com dinheiro suficiente as pessoas chegam bem perto disso porque Se a rede não pode falhar, isso basicamente significa que o cliente não consegue falar com o servidor dois, isso significa que o servidor dois deve estar fora do ar.

[9:31] porque não pode ter sido a rede falhando. Então essa foi uma maneira que as pessoas meio que construíram sistemas de replicação que não sofriam de cérebro dividido. Obrigado. Um. Outra possibilidade seria ter alguns seres humanos para resolver o problema, ou seja, não fazer nada automaticamente, em vez disso ter os clientes Por padrão, os clientes sempre têm que esperar, você sabe, ambas as réplicas responderem ou algo assim, nunca me é permitido prosseguir com apenas uma delas. Mas você pode, sabe, acionar o pager de alguém para tocar, algum ser humano vai à sala de máquinas e meio que olha as duas réplicas e, ou desliga uma, para garantir que ela está definitivamente morta.

[10:08] ou verifica que uma delas de fato travou, e que a outra está viva. E então você está essencialmente usando o humano como o desempate, e o humano é um, você sabe. se ele fosse um computador, seria um ponto único de falha ele mesmo. clube. Então, por muito tempo, as pessoas usaram um ou outro desses esquemas para construir sistemas replicados, e não é, você sabe, Eles podem ser feitos para funcionar. Os humanos não respondem muito rapidamente. E a rede que não pode falhar é cara, mas não é não factível. Um, Mas acabou que você pode realmente construir sistemas automatizados de failover Um, que podem funcionar corretamente diante de redes instáveis, de redes que podem falhar.

[10:50] que podem se particionar. Então essa divisão da rede ao meio onde os dois lados operam mas não conseguem falar um com o outro, Isso geralmente é chamado de partição. Um. Obrigado. Obrigado. E o grande insight que as pessoas tiveram para construir sistemas automatizados de replicação que não sofrem de cérebro dividido é a ideia de voto majoritário. E então isto é-- Obrigado. Obrigado. Obrigado. um conceito que aparece tipo em cada outra frase praticamente no artigo do Raft.

[11:24] É meio que uma forma fundamental-- um modo de proceder. O primeiro passo é ter um número ímpar de servidores em vez de um número par de servidores. Tipo, uma falha aqui é que é um pouco simétrico demais. Os dois lados da divisão aqui, eles simplesmente parecem iguais. Eles rodam o mesmo software, eles vão fazer a mesma coisa, e isso não é bom. Mas se você tem um número ímpar de servidores, Então, Não é mais simétrico. Certo. Pelo menos uma única divisão de rede será presumivelmente dois servidores de um lado e um servidor do outro lado, e eles não serão nem um pouco simétricos.

[11:57] E isso é parte do que os esquemas de voto majoritário estão. apelando. Então, ideia básica é você ter um número ímpar de servidores, para fazer progresso de qualquer tipo, então no Raft, eleger um líder, ou fazer com que uma entrada de log seja confirmada, para fazer qualquer progresso em cada etapa, Você tem que reunir uma maioria... dos servidores, mais da metade, mais da metade de todos os servidores, para meio que aprovar aquela etapa, tipo votar em um líder, aceitar uma nova entrada de log e confirmá-la. Um, Então, você sabe, o mais...

[12:29] uh... A maneira direta é ter dois ou três servidores necessários para fazer qualquer coisa. Um, Uma razão pela qual isso funciona, é claro, é que Se houver uma partição, Não pode haver mais de uma partição com uma maioria dos servidores nela. Essa é uma maneira de ver isso. Uma partição pode ter um servidor nela, o que não é uma maioria. Ou talvez você possa ter dois, mas se uma partição tem dois, então a outra partição tem que ter apenas um servidor nela. e portanto nunca será capaz de reunir uma maioria e não conseguirá fazer progresso.

[13:03] Um, E apenas... Para ser totalmente claro, Quando estamos falando de uma maioria, é sempre uma maioria de todos os servidores. não apenas dos servidores vivos. Este é um ponto que me confundiu por muito tempo, Se você tem um sistema com três servidores, e talvez alguns deles tenham falhado ou algo assim, Se você precisa reunir uma maioria, é sempre dois de três. mesmo se você sabe que um falhou. A maioria é sempre do número total de servidores. um, Há uma formulação mais geral disso. Por causa do sistema de voto majoritário em que dois de três são necessários para fazer progresso, ele pode sobreviver à falha de um servidor.

[13:40] Certo. Quaisquer dois servidores são suficientes para fazer progresso. Se você precisa ser capaz de, se você está, sabe, preocupado com quão confiáveis seus servidores são ou Deus. você pode construir sistemas que têm mais servidores, e então a formulação mais geral é Se você tem dois f mais um servidores, então você pode suportar F falhas. Tchau. Então se são três, Isso significa que f é um. Em um sistema com três servidores, você tolera F servidores, F1 falha e continua funcionando.

[14:16] Obrigado. Obrigado. Obrigado. Tudo bem. Frequentemente esses são chamados de sistemas de quórum porque os dois de três às vezes são considerados um quórum. Obrigado. Ok, então uma propriedade que eu já mencionei sobre esses sistemas de voto majoritário é que Um, No máximo uma partição pode ter uma e portanto se a rede estiver particionada, Não podemos ter ambas as metades da rede fazendo progresso. Outra coisa mais sutil acontecendo aqui é que Um, Se você sempre precisa de uma maioria.

[14:49] dos servidores para prosseguir. E você passa por uma espécie de sucessão de operações em que a cada operação alguém reuniu uma maioria tipo. você sabe, votos para líderes ou Digamos votos para líderes no Raft. A cada passo, a maioria que você reúne para aquele passo deve conter pelo menos um servidor que estava na maioria anterior. quaisquer duas maiorias se sobrepõem em pelo menos um servidor. E é realmente essa propriedade, mais do que qualquer outra coisa, que o Raft está usando.

[15:22] Um, para evitar cérebro dividido. É o fato de que, por exemplo, quando você tem um líder, uma eleição de líder bem-sucedida, e um líder reúne votos de uma maioria, sua maioria tem garantia de se sobrepor à maioria do líder anterior. Então, por exemplo, o novo líder tem garantia de saber sobre o número do termo usado pelo líder anterior. porque sua maioria se sobrepõe à maioria do líder anterior e todos na maioria do líder anterior sabiam sobre o número do termo do líder anterior. Similarmente, qualquer coisa que o líder anterior-- poderia ter confirmado deve estar presente em uma maioria dos servidores no Raft, e portanto a maioria de qualquer novo líder deve se sobrepor a pelo menos um servidor.

[16:01] com cada entrada confirmada. do líder anterior. Esta é uma grande parte do Por que é que... O Raft está correto. Alguma pergunta sobre... o conceito geral de sistema de voto majoritário. Sim? Também é comum adicionar servidores? Tipo adicionar o processamento? JONATHAN GRUBER: É possível adicionar servidores? Acho que é possível. É possível, você sabe, seção algo, talvez seis no como adicionar ou mudar o conjunto de servidores.

[16:41] É possível. Você precisa fazer isso em um sistema de longa duração. Se você está rodando seu sistema por cinco, 10 anos, você vai precisar substituir os servidores depois de um tempo. você sabe, um deles falha permanentemente, ou você faz upgrade, ou você muda a sala de máquinas para uma sala de máquinas diferente. Você realmente precisa ser capaz de suportar a mudança de conjuntos de servidores. Então é isso. Certamente não acontece todo dia, mas é uma parte crítica disso, ou da manutenibilidade de longo prazo desses sistemas. Um, E os autores do RAF meio que se dão tapinhas nas costas Aí está.

[17:12] um esquema que lida com isso, e bem que poderiam porque é complexo. Obrigado. Obrigado. Tudo bem, então usando essa ideia, em cerca de 1990 ou algo assim, houve dois sistemas propostos quase ao mesmo tempo. que perceberam que Você poderia usar esse sistema de voto majoritário para meio que contornar a aparente impossibilidade de evitar cérebro dividido. usando, basicamente usando três servidores em vez de dois, e fazendo votações majoritárias.

[17:44] Um, em um desses sistemas muito antigos era chamado Paxos. O artigo do Raft fala muito sobre isso. Um, E outro desses sistemas muito antigos era chamado replicação de carimbo de visão. Tchau. abreviado como VSR para replicação de carimbo de visão. E embora o Paxos seja de longe o sistema mais amplamente conhecido neste departamento, o Raft é na verdade mais próximo em design ao design da replicação de carimbo de visão. que foi inventado por pessoas do MIT.

[18:15] Um, E então há meio que uma longa história de muitas décadas desses sistemas, e eles só realmente vieram à tona e começaram a ser usados muito em sistemas distribuídos grandes implantados cerca de 15 anos atrás. uns bons 15 anos depois de terem sido originalmente inventados. Ok, então... Então deixe-me falar sobre o Raft agora. O Raft assume a forma de uma biblioteca destinada a ser incluída em algum aplicativo de serviço.

[18:50] E então se você tem um serviço replicado, cada uma das réplicas no serviço vai ser algum código de aplicação que recebe RPCs ou algo assim, mais uma biblioteca raft. E as bibliotecas raft cooperam entre si Um, para manter a replicação. Então, uma espécie de visão geral de software de uma única réplica raft é que no topo podemos pensar na réplica como tendo o código de aplicação. Então pode ser para o laboratório três, um servidor de chave-valor. Então talvez tenhamos algum servidor de chave-valor.

[19:22] E ele tem estado, a aplicação tem estado que o raft está ajudando a gerenciar, estado replicado. E para um servidor de chave-valor, vai ser uma tabela de chaves e valores. Um... *batendo* A próxima camada abaixo é uma camada raft. Então o servidor de chave-valor vai fazer chamadas de função para o RAFT, e eles vão conversar um pouco de um lado para o outro. o raft mantém um pouco de estado. Você pode ver na figura dois. E para nossos propósitos, realmente a peça mais crítica de estado é que o raft tem um log de operações.

[20:01] Obrigado. Ok. Obrigado. Amém. E em um sistema com três réplicas, na verdade vamos ter três servidores que têm exatamente a mesma estrutura idêntica e esperançosamente os mesmos dados sentados em. sentados em ambas as camadas. Obrigado. Amém. Obrigado. Obrigado. Obrigado. Obrigado. Obrigado.

[20:31] Obrigado. Certo. Fora disso, vai haver clientes. E o jogo é que Então temos cliente um, cliente dois, um monte de clientes. Os clientes realmente não sabem, os clientes são, você sabe, código externo que precisa ser capaz de usar o serviço. e A esperança é que os clientes realmente não precisem estar cientes de que estão falando com um serviço replicado. Que para os clientes vai parecer quase como se fosse apenas um servidor e eles falam com um servidor. E então os clientes na verdade enviam requisições de cliente para A chave para a camada de aplicação.

[21:05] do líder atual, a réplica que é o líder atual no Raft. E então essas vão ser requisições de nível de aplicação para um banco de dados para um servidor de chave-valor, essas podem ser requisições put e get. put pega uma chave e um valor e atualiza a tabela e get pede ao serviço para obter a chave atual, o valor atual correspondente a Alguma chave. Então isso não tem muito a ver com o Raft. É apenas interação cliente-servidor para qualquer serviço que estejamos construindo.

[21:39] Hum, mas quando um desses comandos é enviado a partir da requisição, é enviado do cliente para o servidor, o que realmente acontece é que, em um servidor não replicado, o código da aplicação executaria essa requisição e digamos, atualizaria a tabela em resposta a um put. Mas não em um serviço replicado com RAPT. Em vez disso, se assumirmos que o cliente envia uma requisição para o líder, o que realmente acontece é que a camada de aplicação simplesmente envia a requisição, a requisição do cliente, para baixo, na camada RAFT, dizendo: "Olha, aqui está uma requisição.

[22:10] Por favor, faça com que ela seja confirmada no log replicado e me avise quando terminar. E então, neste ponto, os rafts conversam entre si. Hum. até que todas as réplicas ou uma maioria das réplicas tenham essa nova operação em seus logs. Então ela está replicada, e então quando está... E o líder sabe que todas as réplicas têm uma cópia disso, só então é enviada uma notificação de volta para cima, para a camada de chave-valor, dizendo: "Ah, aquela operação que você me enviou um minuto atrás, agora foi confirmada em todas as réplicas. E então está replicada com segurança e neste ponto tudo bem executar essa operação.

[22:53] É um raft. O cliente envia uma requisição para a camada de chave-valor, a camada QDialy ainda não a executa. Então não temos certeza. porque ela ainda não foi replicada. Só quando está nos logs de todas as réplicas. Tchau. Então o Raph notifica o líder, e agora o líder realmente executa a operação, o que corresponde a... você sabe, para um put, atualizar a tabela de chave-valor; para um get, ler o valor correto da tabela, e então finalmente envia a resposta de volta ao cliente.

[23:26] Então essa é uma operação comum do Obrigado. . Ela é submetida se estiver em uma maioria. E, novamente, a razão pela qual não pode ser todas é que, se quisermos construir um sistema tolerante a falhas, ele precisa ser capaz de fazer progresso mesmo se alguns dos servidores tiverem falhado. Então-- Hum, Sim. Ela é confirmada quando está em uma maioria. Obrigado. Sim. Então, antes que o líder execute a requisição, as propriedades de valor de mercado.

[24:00] Hum... que foram replicadas. Obrigado. Uau. - Desculpe. Obrigado. líderes Sim, entendi. E então. Além disso, quando as operações finalmente são confirmadas, cada uma das réplicas envia a operação para cima. Cada camada da biblioteca wraths envia a operação para cima, para a camada de aplicação local, e a camada de aplicação local aplica essa operação ao seu estado. E então todas elas... Então, esperançosamente, todas as réplicas veem o mesmo fluxo de operações.

[24:31] elas aparecem nessas chamadas de cima na mesma ordem, são aplicadas ao estado na mesma ordem, e você sabe, assumindo que as operações são determinísticas, o que é melhor que sejam, Hum, o estado... do estado replicado evoluirá de forma idêntica em todas as réplicas. Então, tipicamente, esta tabela é do que o artigo está falando quando fala de estado. Obrigado. uma maneira diferente de ver essa interação, e uma que terá uma espécie de notação que aparecerá muito neste curso, é que Hum, uma espécie de diagrama de tempo, vou desenhar um diagrama de tempo de como as mensagens funcionam.

[25:12] Então vamos imaginar que temos um cliente, e o Servidor um é o líder, e também temos o servidor dois. Obrigado. Servidor três, e o tempo flui para baixo neste diagrama. Imaginamos o cliente enviando a requisição original para o servidor um. Obrigado. Depois disso, a camada wrapped do servidor um. Hum, envia uma append entry, é RPC. Hum, para cada uma das duas réplicas. Obrigado. Esta é apenas uma requisição comum, digamos, de put.

[25:45] Isto é, estas são requisições de PEND entries. Obrigado. O servidor agora está esperando respostas. dos servidores, das outras réplicas, assim que houver respostas de uma maioria, uma volta, incluindo o próprio líder. Então, em um sistema com apenas três réplicas, o líder só precisa esperar por uma outra réplica. para responder positivamente a uma appendentary assim que ela reúne. respostas positivas de uma maioria. Hum, o Líder executa o comando, descobre qual é a, Resposta, tipo, esquece.

[26:20] hum e envia a resposta de volta para o... E enquanto isso, é claro, você sabe, se S2 estiver realmente vivo, ele vai, você sabe, enviar de volta a resposta também, mas não estamos esperando por ele. Obrigado. É útil saber na figura dois. Obrigado. Certo, todos veem isto? Obrigado. Esta é a espécie de operação comum do sistema. Sem falhas aqui. Oh, certo. Nossa, sim. Eu gosto...

[26:53] Eu deixei de fora-- um passo importante. Neste ponto, o líder sabe, oh, eu tenho uma maioria que colocou no log deles, posso prosseguir e executar e responder sim ao cliente porque é... O Servidor dois ainda não sabe de nada. Ele só sabe, bem, você sabe, eu recebi esta requisição do, mas não sei se ela já foi confirmada. Depende de, por exemplo, se minha resposta chegou de volta ao líder. Pelo que o Servidor 2 sabe, sua resposta foi descartada pela rede, talvez o líder nunca tenha ouvido a resposta e nunca tenha decidido confirmar esta requisição. Na verdade, há outro estágio, uma vez que o, Servidor.

[27:24] percebe que uma requisição foi confirmada, ele então precisa informar às outras réplicas esse fato. E Amém. Então há... Uh... Há uma mensagem extra aqui. Exatamente qual é essa mensagem depende um pouco do que mais está acontecendo. pelo menos no RAF, não há uma mensagem de confirmação explícita. Em vez disso, a informação é transportada dentro das próximas append entries que o líder envia. As próximas RPCs de append entries que ele envia por qualquer motivo.

[27:58] Tipo, há um campo de, commit, leader commit ou algo assim nessa RPC. e Na próxima vez que o líder precisar enviar um heartbeat ou algo assim, precisar enviar uma nova requisição de cliente porque algum cliente diferente. requisitar algo, ele enviará o Hum, Novo, mais alto. valor de leader commit e nesse ponto o, uh, Hum, sim. as réplicas executarão a operação e a aplicarão ao seu estado. Sim.

[28:29] Obrigado. Obrigado. Oh, sim. Então este é um, Este é um protocolo que tem bastante conversa. Hum, e não é super rápido. De fato, você sabe, sim, o cliente envia uma requisição, a requisição tem que chegar ao servidor, o servidor fala com pelo menos, você sabe, outro... Ele envia múltiplas mensagens, tem que esperar pelas respostas, envia algo de volta. Então há um monte de tempos de ida e volta de mensagens meio que.

[29:02] embutidos aqui. teria feito sentido para a segunda parte da faculdade. Obrigado. Sim, então... Se... Então, isso depende de você como implementador exatamente quando o líder envia o índice de confirmação atualizado. Se-- as requisições de cliente voltarem só muito ocasionalmente. então o líder pode querer enviar um heartbeat ou enviar uma mensagem especial de append entries.

[29:34] Hum, Se as requisições de cliente chegarem com bastante frequência, então não importa, Se chegarem, você sabe, se chegarem mil por segundo, então, nossa, haverá outra chegando muito em breve. E então você pode transportar junto. Então, sem gerar uma mensagem extra, o que é um tanto caro. você pode levar a informação na próxima mensagem que vai enviar de qualquer forma. Hum, Na verdade, eu não acho que o momento em que as réplicas executam a requisição seja crítico porque ninguém está esperando por isso, pelo menos se não houver falhas. Se não houver falhas, a execução da requisição pelas réplicas não está realmente no caminho crítico.

[30:12] Tipo, o cliente não está esperando por elas, o cliente só está esperando o líder executar. Então pode não ser tão importante. hum Pode não afetar a latência percebida pelo cliente, tipo, exatamente como isso é encenado. Hum. Tchau. Obrigado. Obrigado. Obrigado. Obrigado. Obrigado. Obrigado. Certo. Uma pergunta que você deveria fazer é por que o sistema é tão focado em logs? O que os logs estão fazendo?

[30:51] E vale a pena tentar chegar a respostas explícitas para isso. Uma resposta para por que o sistema é totalmente focado em logs é que o log é o tipo de mecanismo pelo qual o líder ordena as operações. É vital para essas máquinas de estado replicadas que todas as réplicas apliquem não apenas as mesmas operações de cliente ao seu estado, mas as mesmas operações na mesma ordem. Mas todas elas têm que aplicar essas operações vindas dos clientes na mesma ordem. E o log, entre muitas outras coisas, é parte da maquinaria pela qual o líder atribui uma ordem às operações de cliente que chegam.

[31:32] você sabe, 10 clientes enviam operações para o líder. Ao mesmo tempo, o líder tem que escolher uma ordem, garantir que todos, todas as réplicas obedeçam a essa ordem. E o log é... O fato de o log ter slots numerados é parte de como o líder expressa a ordem que escolheu. Hum, Obrigado. Outro uso do log é que entre este ponto e este ponto, o Servidor 3 recebeu uma operação da qual ainda não tem certeza de que foi confirmada. e ele não pode executá-la ainda. Ele tem que colocar essa operação de lado em algum lugar.

[32:06] até que o incremento do valor de leader commit chegue. E então, outra coisa que o log está fazendo é que, nos seguidores, o log é o lugar onde o seguidor meio que separa operações que ainda são provisórias. que chegaram mas ainda não se sabe que foram confirmadas. E elas podem ter que ser descartadas, como veremos. Hum, Então esse é outro uso. No tipo de contrapartida desse uso no lado do líder está que o líder precisa lembrar das operações em seu log porque pode precisar retransmiti-las.

[32:38] para os seguidores. Se algum seguidor estiver offline, talvez algo tenha acontecido brevemente com sua conexão de rede ou algo assim, ele perde algumas mensagens. O líder precisa ser capaz de reenviar mensagens do blog que qualquer seguidor perca. E então o líder precisa de um lugar onde possa separar cópias de mensagens de requisições de cliente, mesmo aquelas que já executou. para poder reenviá-las ao cliente. Quero dizer, enviá-las para réplicas que perderam essa operação. E uma razão final para todos eles manterem o log é que, pelo menos no mundo da figura dois, se um servidor cair e reiniciar e quiser se juntar novamente, hum, você realmente quer que um servidor que caiu de fato reinicie e se junte novamente.

[33:20] ao cluster wrapped, caso contrário você agora está operando com apenas dois de três servidores e não pode mais sobreviver a nenhuma falha. Precisamos reincorporar servidores que falharam e reiniciaram, e o log é meio que onde, o que um servidor, um servidor reiniciado usa. O log persistido em seu disco. Porque uma das regras é que cada servidor Rath precisa gravar seu log em seu disco, onde ele ainda estará depois que cair e reiniciar. Esse log é o que o servidor usa, ele reproduz as operações nesse log desde o início para meio que criar seu estado como era quando caiu.

[33:52] e então continua a partir daí. Então o log também é usado como parte do plano de persistência. como uma sequência de comandos para reconstruir o estado. Sim. Então eu me pergunto quais cenários surgiriam em que os workers estão tentando acompanhar isso. Uh... Bem, em última análise, Ok, então a pergunta é, Suponha que o líder seja capaz de executar mil comandos de cliente por segundo e os seguidores sejam capazes de executar apenas cem comandos de cliente por segundo. Esse tipo de taxa sustentada em velocidade máxima.

[34:32] hum A, então uma coisa a notar é que as, as As réplicas, os seguidores, confirmam os comandos antes de executá-los. Então a taxa na qual eles confirmam e acumulam coisas em seus logs não é limitada. Então, você sabe, talvez eles possam confirmar, mil requisições por segundo. Se fizerem isso para sempre, então eles acumularão. logs de tamanho ilimitado porque sua taxa de execução ficará um tanto ilimitado atrás da taxa na qual o líder entregou as mensagens, meio que sob as regras do nosso jogo.

[35:06] E então o que isso significa é que eventualmente ficará sem memória. Em algum momento, depois que tiverem um bilhão, depois que ficarem um bilhão de entradas de log atrasadas, eles simplesmente, é chamado de alocador de memória. por espaço para uma nova entrada de log e isso falhará. Hum, então sim, e o RAF não, hum, o RAP não tem os controles de fluxo necessários para lidar com isso. Então eu acho que... em um sistema real, você provavelmente precisaria de algo acoplado e não precisa ser em tempo real, mas você provavelmente precisa de algum tipo de hum, comunicação adicional aqui que diga: "Oh, aqui está o quão longe eu cheguei na execução."

[35:47] Para que o líder possa dizer: bem, estou milhares de requisições à frente do ponto em que os seguidores executaram. Sim, então eu acho que provavelmente em um sistema de produção que você está tentando levar ao máximo absoluto. você bem que pode precisar de uma mensagem extra para limitar o líder se ele ficar muito à frente. Obrigado. Ok.

[36:33] - Então a questão é: se um desses servidores falhar, ele tem esse log que persistiu em disco, porque essa é uma das regras da figura dois. hum Então o servidor poderá simplesmente ser carregado de volta do disco, mas é claro, esse servidor não sabe até onde chegou na execução do log. E também não sabe, pelo menos quando reinicia pela primeira vez, pelas regras da Figura 2. Ele nem sabe quanto do log está confirmado. Então a primeira resposta para sua pergunta é que imediatamente após uma reinicialização, depois que um servidor falha e reinicia e lê esse log, ele não tem permissão para fazer nada com o log.

[37:09] porque ele não sabe até onde o sistema confirmou em seu log. Talvez esse log tenha mil entradas não confirmadas e zero entradas confirmadas para todos Então... Se o líder morrer, é claro, isso também não ajuda. Vamos supor que todos falharam. Isso está se adiantando... Está se adiantando um pouco para mim, mas vamos supor que todos falharam, e então tudo o que têm é o estado que foi marcado como não volátil na figura dois, que inclui o log e talvez o último termo.

[37:43] Hum, E então eles não sabem. Então, se houver uma falha, se todos falharem e todos reiniciarem, nenhum deles sabe. inicialmente até onde eles tinham executado antes da falha. Então o que acontece é que eles fazem eleição de líder, um deles é escolhido como líder. E esse líder, se você acompanhar o que a figura dois diz sobre como os append entries devem funcionar. o líder na verdade descobrirá como subproduto do envio do primeiro heartbeat, na verdade.

[38:14] Hum, Ele descobrirá qual é o ponto mais recente basicamente que esse Amém. todos os, que uma maioria das réplicas concorda em seu log. Porque esse é o ponto de confirmação. Outra maneira de ver isso é que, uma vez que você escolhe um líder, através do mecanismo de append entries, o líder força todas as outras réplicas a terem logs idênticos ao do líder. E nesse ponto, mais...

[38:45] Um pouco de extra, o artigo explica. Nesse ponto, como o líder sabe que forçou todas as réplicas a terem logs idênticos aos dele. Então ele sabe que, oh, todas as réplicas também devem ter um-- Deve haver uma maioria de réplicas com- que todas aquelas entradas de log nos logs que agora são idênticos também devem estar confirmadas porque estão mantidas em uma maioria de réplicas. Hum, E nesse ponto, o líder-- o código de append entries descrito na figura dois para o líder incrementará o ponto de confirmação do líder e e todos agora podem executar o log inteiro desde o início.

[39:22] e recriar seu estado do zero. possivelmente de forma extremamente trabalhosa. Hum... Então é isso que a figura dois diz. É obviamente que essa reexecução do zero não é muito atraente, mas é o que o protocolo básico faz. E veremos amanhã. versão disso é mais eficiente, usa checkpoints e falaremos sobre isso amanhã. Obrigado. Ok, então esta foi uma sequência em operação normal, sem falhas.

[39:53] Hum, hum... Outra coisa que quero mencionar brevemente é como essa interface se parece. Vocês provavelmente já viram um pouco dela. devido ao trabalho nos laboratórios, mas grosso modo, se você tem, digamos, esta camada de chave-valor, com seu estado. e a camada raft abaixo dela, há Em cada réplica há realmente duas peças principais. da interface entre elas. Há este... Hum, método pelo qual a camada de chave-valor pode retransmitir. Se um cliente envia uma requisição, a camada de chave-valor tem que entregá-la ao Raft e dizer: "Por favor, você sabe, encaixe esta requisição no log em algum lugar, e essa é a função start.

[40:34] Hum. que você verá em raft.go. E realmente ela só recebe um argumento, o comando do cliente. Obrigado. A camada de chave-valor está dizendo: "Por favor, recebi este comando. Coloque-o no log e me avise quando estiver confirmado." E a outra peça da interface é que, oportunamente, A camada raft notificará a camada de chave-valor que, ah, aquela operação que você me enviou em um comando start há um tempo atrás, que pode muito bem não ser o start mais recente. Cem comandos de cliente podem chegar e causar chamadas a start antes que qualquer um deles seja confirmado.

[41:09] oportunamente Hum, esta-- comunicação ascendente assume a forma de uma mensagem em um canal Go no qual a biblioteca Raft envia e a camada de chave-valor. deve ler. Hum. Então há este apply, Obrigado. Obrigado. É chamado de canal apply, e nele você envia uma mensagem apply. Obrigado. Não sei. Obrigado. Obrigado. Obrigado. este start e é claro que você precisa que a camada de chave-valor consiga correlacionar as mensagens que recebe no canal Apply com as chamadas a start que fez.

[41:47] Hum, E então o comando start na verdade retorna informação suficiente para que essa correlação aconteça. Ele retorna o índice a função start basicamente retorna o índice no log onde, se este comando for confirmado, o que pode não acontecer, ele será confirmado neste índice. Hum, E eu acho que também retorna o termo atual, e algumas outras coisas com as quais não nos importamos muito. E então esta mensagem apply vai conter o índice. tanto o Comando.

[42:20] Hum. Obrigado. Obrigado. Obrigado. Obrigado. Obrigado. e o índice. E todas as réplicas receberão essas mensagens apply, então todas saberão: "Oh, eu devo aplicar este comando." hum descobrir o que este comando significa e aplicá-lo ao meu estado local. E elas também recebem o índice. O índice só é realmente útil no líder para que ele possa descobrir. de quais requisições de cliente estamos falando. Obrigado. Estou curioso sobre o seguinte. O cliente está enviando sua requisição para o líder do raft em qualquer lugar.

[42:59] no qual-- clientes fazendo um get-go. Certo. sobre isso. OK. OK. Hum, acho que respondi a uma pergunta um pouco diferente. Vamos supor que o cliente envie qualquer requisição, Digamos que seja um put ou um get. Pode ser um put ou um get. Não importa muito. Vou considerar get. Hum, o ponto em que o Então o cliente envia novamente e espera por uma resposta. O ponto em que o líder enviará uma resposta é depois que o líder sabe que aquele comando está confirmado.

[43:40] Então isso vai ser uma espécie de resposta get. Tchau. *batendo* Tchau. Então o cliente não vê nada de volta. Quero dizer, e então, hum, Isso significa em termos da pilha de software real, Isso significa que a chave-valor, o RPC chegará, a camada de chave-valor chamará a função start. A função start retornará para a camada de chave-valor Mas-- A camada de chave-valor ainda não responderá ao cliente porque não sabe se é Na verdade, ela não executou a requisição do cliente agora. Ela nem sabe se algum dia executará.

[44:14] porque não tem certeza se a requisição será confirmada. E a situação em que pode não ser confirmada é se a camada de chave-valor, você sabe, recebe uma requisição, chama start, e imediatamente após start retornar, ela falha. Certamente não enviou suas mensagens apply, ou o que quer que seja. Nada foi confirmado ainda. Hum, Então o jogo é start retorna. o tempo passa, a mensagem apply relevante correspondente àquela requisição do cliente aparece para o servidor de chave-valor no canal apply e só então e isso faz com que o servidor de chave-valor execute a requisição E-- Envie uma resposta.

[44:52] Obrigado. Obrigado. Obrigado. Obrigado. Obrigado. E isso é tipo-- tudo isso é É muito importante quando Isso não importa muito se tudo correr bem. Mas se houver uma falha, agora estamos-- No ponto em que começamos a nos preocupar com falhas, estaremos extremamente interessados em, se houve uma falha, o que o cliente viu? Hum, Obrigado. Certo. E então uma coisa que surgiu é... isso é, hum, todos vocês devem estar familiarizados com isso é que, pelo menos inicialmente, uma coisa interessante sobre os logs é que eles podem não ser idênticos.

[45:30] Há toda uma série de situações em que, pelo menos por breves períodos de tempo, os finais dos diferentes... logs das réplicas podem divergir, como por exemplo, se um líder começa a enviar uma rodada de mensagens append, mas falha antes de conseguir enviar todas. Isso significará que algumas das réplicas que receberam a mensagem append acrescentarão, você sabe, aquela nova entrada de log, e as que não receberam aquela mensagem append como RPC, não as terão acrescentado. Então é fácil ver que os logs vão divergir às vezes. A boa notícia é que, a A forma como o Raft funciona na verdade acaba forçando os logs a serem idênticos depois de um tempo.

[46:07] porque pode haver diferenças transitórias, mas a longo prazo, todos os logs serão meio que modificados pelo líder até que o líder garanta que todos sejam idênticos e só então Hum. Ok. Eu acho que o próximo, há realmente dois grandes tópicos. para falar aqui sobre o Raft. Um é como funciona a eleição de líder, que é o Lab 2. E o outro é como o líder lida com os logs das diferentes réplicas, particularmente após falha.

[46:38] Então primeiro quero falar sobre eleição de líder. Amém. Obrigado. A pergunta a fazer é como o sistema sequer tem um líder? Por que precisamos de um líder? parte da resposta é que você não precisa de um líder para construir um sistema como este. É possível construir. um sistema de acordo pelo qual um cluster de servidores concorda sobre, você sabe, a sequência de entradas em um log sem ter nenhum tipo de líder designado. E de fato, o sistema Paxos original, ao qual o artigo se refere, o Paxos original não tinha um líder.

[47:11] Hum, Então é possível. A razão pela qual o Raft tem um líder é basicamente que Hum, Provavelmente há muitas razões, mas uma das principais razões é que você pode construir um sistema mais eficiente no caso comum em que todos os servidores não falham. É possível construir um sistema mais eficiente se você tiver um líder. Porque com um líder designado, todos sabem quem é o líder, Você pode basicamente obter acordo sobre requisições com uma rodada de mensagens por requisição. Enquanto sistemas sem líder têm mais o estilo de, bem, você precisa de uma primeira rodada para meio que concordar com um líder temporário, e então uma segunda rodada para realmente enviar a requisição.

[47:49] Então, é provavelmente o caso que o uso de um líder acelera o sistema por um fator de dois. Obrigado. E também torna mais fácil pensar sobre o que está acontecendo. Obrigado. Hum, O Raft passa por uma sequência de líderes, E usa esses números de termo para meio que desambiguar de qual líder estamos falando. Acontece que os seguidores não precisam realmente saber a identidade do líder. Eles realmente só precisam saber qual é o número do termo atual.

[48:20] Cada mandato tem no máximo um líder. É isso. Propriedade crítica. Você sabe, para cada mandato, pode não haver líder durante aquele mandato, ou pode haver um líder, mas não pode haver dois líderes durante o mesmo mandato. Cada mandato tem no máximo um líder. Hum, obrigado. Obrigado. Como os líderes são criados em primeiro lugar? Cada... servidor empacotado. mantém este temporizador de eleição, que é apenas um É basicamente apenas um tempo que ele registrou que diz, bem, se esse tempo ocorrer, eu vou fazer algo.

[48:55] hum E algo que ele faz é que se um período inteiro de eleição de líder expirar, sem que o servidor tenha ouvido nenhuma mensagem do líder atual, então o servidor meio que assume que provavelmente o líder atual está morto e começa uma eleição. Então temos este temporizador de eleição. E se expirar, começa uma eleição. Obrigado. .

[49:26] Obrigado. Hum, E o que significa começar uma eleição é basicamente que você incrementa o mandato o candidato, o servidor que decidiu que vai ser candidato e meio que força uma nova eleição, primeiro incrementa este mandato porque, você sabe, quer que ela seja um novo líder, ou seja, ele mesmo, E um mandato não pode ter mais de um líder, então temos que começar um novo mandato. para ter um novo líder. E então ele envia esses pedidos de voto, RPCs.

[49:57] Obrigado. Vou enviar uma rodada completa de pedidos de voto. E você pode ter que enviar apenas n menos um pedidos de voto, porque uma das regras é que um novo candidato sempre vota em si mesmo. na eleição. Hum, Então. Uma coisa a notar sobre isso é que Não é bem o caso que se um líder não falhou, não teremos uma eleição. ou se o líder falhar, então teremos uma eleição assumindo que qualquer outro servidor esteja ativo, porque algum dia os temporizadores de eleição dos outros servidores dispararão.

[50:28] Mas se o líder não falhou, ainda podemos, infelizmente, ter uma eleição. Então, se a rede estiver lenta ou perder alguns heartbeats ou algo assim, podemos acabar tendo temporizadores de eleição disparando, e mesmo que houvesse um líder perfeitamente bom, podemos, no entanto, ter uma nova eleição. Então temos que meio que manter isso em mente quando pensamos sobre correção. Hum, E o que isso por sua vez significa é que se houver uma nova eleição, pode facilmente ser o caso de o antigo líder ainda estar por aí e ainda pensar que é o líder. Como, se houver uma partição de rede, por exemplo, E o antigo líder ainda estiver vivo e bem em uma partição minoritária.

[51:02] A partição majoritária pode realizar uma eleição, e de fato uma eleição bem-sucedida, e escolher um novo líder. totalmente desconhecido para o líder anterior. Então também temos que nos preocupar com, você sabe, oh, o que aquele líder anterior vai fazer já que ele não sabe que houve uma nova eleição? Obrigado. Muito obrigado. Obrigado. Obrigado.

[51:43] Então a questão é: Existem, podem existir casos patológicos nos quais, por exemplo, A comunicação de rede unidirecional pode impedir o sistema de fazer progresso. Acredito que a resposta é sim. Certamente. Então, por exemplo, se o líder atual, Se sua rede de alguma forma falhar pela metade de um modo que o líder atual possa enviar heartbeats mas não possa receber nenhuma requisição de cliente. então os heartbeats que ele envia, que são entregues porque sua conexão de rede de saída funciona. Seus heartbeats de saída suprimirão qualquer outro servidor de iniciar uma eleição.

[52:20] Mas o fato de que seu fio de rede de entrada aparentemente está quebrado o impedirá de ouvir e executar quaisquer comandos de cliente. Era absolutamente o caso que o RAPT não é à prova de todos os hum tipos de todos os problemas malucos de rede que podem surgir. Acredito que os que pensei, acredito que são corrigíveis no sentido de que o Poderíamos resolver este aqui tendo um tipo de exigir um heartbeat bidirecional no qual se o líder envia heartbeats mas no qual Os seguidores são obrigados a responder de alguma forma aos heartbeats, como eles já são obrigados a responder.

[52:58] Mas se o líder parar de ver respostas aos seus heartbeats, Então após algum tempo em que a estação foi substituída, o líder decide renunciar. Sinto que esse problema específico. pode ser corrigido. e muitos outros também podem, mas eu, mas, Sim. você sabe Você está absolutamente certo. Coisas muito estranhas podem acontecer com redes, incluindo algumas para as quais o protocolo não está preparado. Obrigado. Obrigado. Obrigado.

[53:29] Ok, então temos essas eleições de mandato. Precisamos garantir que haja no máximo, no máximo, um líder por mandato. Como o RAF faz isso? Bem, o RAF exige, para ser eleito para um mandato, o RAF exige que um candidato obtenha votos sim de uma maioria dos servidores. Os servidores e cada servidor só dará um voto sim por mandato. Então, em qualquer mandato dado, você sabe, isso basicamente significa que em qualquer mandato dado, cada servidor vota apenas uma vez para apenas um candidato, Hum, Você não pode ter dois candidatos ambos obtendo maioria dos votos porque Todos votam apenas uma vez.

[54:06] Hum, Então a maioria-- A regra da maioria faz com que haja no máximo um candidato vencedor. Hum, e Então temos no máximo um. candidato eleito por turno. Hum... E além disso, criticamente, a regra da maioria significa que você pode ser eleito mesmo se alguns servidores tiverem falhado. Se uma minoria dos servidores falhou ou está indisponível, tem problemas de rede, ainda podemos eleger um líder. Se mais da metade falhou ou não está disponível ou está em outra partição ou algo assim, então Na verdade, o sistema simplesmente ficará lá tentando repetidamente eleger um líder.

[54:46] e nunca eleger um. se não puder de fato, se eles não forem uma maioria de servidores vivos. hum Obrigado. Se uma eleição for bem-sucedida, Todos, seria ótimo se todos soubessem disso. 7 minutos mais ou menos. Precisamos nos perguntar como todas as partes ficam sabendo o que aconteceu? O servidor que vence uma eleição, assumindo que não falhe, O servidor que vence a eleição na verdade verá uma maioria ou votos positivos para seu pedido de voto de uma maioria dos outros servidores. O candidato que está conduzindo a eleição que a vence, o candidato que vence a eleição saberá diretamente, eu obtive uma maioria de votos.

[55:23] Mas ninguém mais sabe diretamente quem foi o vencedor ou se alguém venceu. Hum, Então a maneira como o candidato informa os outros servidores é aquele heartbeat. as regras na Figura 2 dizem, oh, se você vencer uma eleição, você é imediatamente obrigado a enviar append entries. para todos os outros servidores. Agora, append entries aquele heartbeat append entries não diz explicitamente, eu venci a eleição, você sabe, eu sou um líder para o mandato 23. Hum, É um pouco mais sutil que isso. a maneira como a informação é comunicada é que Hum, Ninguém tem permissão para enviar append entries a menos que seja um líder para aquele mandato.

[56:02] Então o fato de que eu sou um, você sabe, eu sou um, Servidor e eu vi, oh, há uma eleição para o mandato 19. E então, aos poucos, eu envio append entries cujo mandato é 19, Isso me diz que alguém, não sei quem, mas alguém venceu a eleição. Hum, então é assim que os outros servidores sabem, é que eles estavam recebendo append entries para aquele mandato. E esse append entries também tem o efeito de, resetar o temporizador de eleição de todos. temporizador. Então, enquanto o líder estiver ativo e enviar mensagens de heartbeat ou append entries pelo menos, você sabe, na taxa que deveria, Toda vez que um servidor recebe um append entry, ele resetará seu temporizador de eleição e meio que suprimirá qualquer um de ser um novo candidato.

[56:46] Então, enquanto tudo estiver funcionando, os heartbeats repetidos impedirão quaisquer eleições adicionais. Claro, se a rede falhar ou pacotes forem perdidos, pode haver, no entanto, uma Mas se tudo correr bem, é meio improvável que tenhamos uma eleição. Hum, Este esquema poderia falhar no sentido, bem, não pode falhar no sentido de eleger. dois líderes para um mandato, mas pode falhar no sentido de eleger zero líderes para um mandato. Hum, A maneira mais comum de falhar é que se muitos servidores estiverem mortos ou indisponíveis ou tiverem conexões de rede ruins. Então, se você não conseguir reunir uma maioria, você não pode ser eleito, nada acontece.

[57:22] Hum, A maneira mais interessante pela qual uma eleição pode falhar é se Todos estiverem ativos. Você sabe, não há falhas, nenhum pacote é perdido. Mas-- dois líderes se tornam candidatos próximos o suficiente no tempo para que dividam o voto entre eles. ou digamos três líderes. Hum, Então suponhamos que temos três líderes. Suponhamos que temos um sistema de três réplicas Hum, Todos os seus temporizadores de eleição disparam ao mesmo tempo.

[57:53] Cada servidor vota em si mesmo. E então quando cada um deles recebe um pedido de voto de outro servidor, bem, ele já deu seu voto a si mesmo e então diz não. Então isso significa que todos os três servidores recebem um voto cada, ninguém obtém maioria, e ninguém é eleito. Hum, Então-- Seus temporizadores de eleição dispararão novamente porque O temporizador de eleição só é resetado se receber um append entries, mas não há líder, Todos terão seus temporizadores de eleição disparando novamente. E se tivermos azar, todos dispararão ao mesmo tempo. Todos votarão em si mesmos. Ninguém obterá maioria. uh Então.

[58:24] Então claramente, tenho certeza que todos vocês já perceberam a esta altura, há mais nesta história. E a maneira como o raft D-- torna a possibilidade de votos divididos improvável, mas não impossível, é randomizando esses temporizadores de eleição. Então a maneira de pensar nisso E a randomização, bem, A maneira de pensar nisso é que, então temos alguma linha do tempo, vou, hum, desenhar eventos nela. Há algum ponto em que todos receberam o último append entries.

[58:56] E então talvez o servidor tenha morrido. Vamos apenas assumir que o servidor enviou um último heartbeat e então morreu. Bem, todos os seguidores têm-- ou resetaram seus temporizadores de eleição quando receberam, ao mesmo tempo, porque provavelmente todos receberam o append entries ao mesmo tempo. Todos resetaram seus temporizadores de eleição. para algum ponto no futuro, para disparar em algum ponto no futuro. eles escolheram tempos aleatórios diferentes no futuro que então iriam disparar. Então suponho que o líder morto é o servidor um, Então agora o servidor dois e o servidor três neste ponto, definem seus temporizadores de eleição para um ponto aleatório no futuro. Digamos que o servidor dois definiu seu, hum, eu gostaria que algum temporizador disparasse aqui.

[59:38] e o servidor três definiu. Seu temporizador de eleição para disparar ali. e O ponto crucial desta imagem é que assumindo que eles escolham números aleatórios diferentes, Um deles é o primeiro e o outro é o segundo. Certo? É isso que está acontecendo aqui. E o que é o primeiro, assumindo que Esta lacuna é grande o suficiente. o que é o Primeiro, este temporizador de eleição disparará primeiro antes do temporizador de eleição do outro. desde que não tenhamos azar, ele terá tempo de enviar uma rodada completa de pedidos de voto.

[1:00:10] e obter respostas de todos onde todos estão vivos antes do segundo temporizador de eleição. disparar de qualquer outro servidor. Hum, Então. Todos veem? como a randomização dessincroniza esses candidatos. Infelizmente, há um pouco de arte em definir as constantes para esses temporizadores de eleição. Há algum tipo de requisitos concorrentes que você pode querer cumprir. Hum, Então um requisito óbvio é que o temporizador de eleição deve ser pelo menos tão longo quanto o intervalo esperado entre heartbeats.

[1:00:48] É bem óbvio que o líder envia heartbeats a cada 100 milissegundos; é melhor você garantir, sabe, não faz sentido ter o timer de eleição de ninguém disparando por 100 milissegundos, porque aí ele dispararia antes mesmo de podermos esperar uma nova entrada de append. Então o limite inferior é certamente o limite inferior é um intervalo de heartbeat. Na verdade, como a rede pode perder pacotes, você provavelmente quer que o valor mínimo do timer de eleição seja algumas vezes o intervalo de heartbeat. Então, para heartbeats de 100 milissegundos, você provavelmente quer que o menor timer de eleição possível seja, digamos, 300 milissegundos.

[1:01:25] três vezes o intervalo de heartbeat. Hum, então esse é o tipo de mínimo é o... Hum, veja, se os heartbeats são dessa frequência, você quer que o mínimo seja algumas vezes isso ou aqui. Hum, então e quanto ao máximo? Você sabe, você presumivelmente vai randomizar uniformemente sobre algum intervalo de tempos. Sabe, onde devemos definir o-- tipo de máximo. Obrigado. sobre o qual estamos randomizando. E há algumas...

[1:01:55] considerações aqui em um sistema real. hum, sabe, esse tempo máximo, uh... afeta quão rápido o sistema pode se recuperar de uma falha porque lembre-se, desde o momento em que o servidor falha até o primeiro timer de eleição disparar, o sistema inteiro fica congelado. Não há líder. Sabe, as requisições dos clientes estão sendo descartadas porque não há líder. e não estamos atribuindo um novo líder mesmo que, sabe, presumivelmente esses outros servidores estejam ativos.

[1:02:26] Então, quanto maior escolhermos esse máximo, maior o atraso que impomos aos clientes antes que a recuperação ocorra. Sabe, se isso é importante depende do tipo de desempenho que precisamos e com que frequência achamos que haverá falhas. Se a falha acontece uma vez por ano, então quem se importa? Hum, se esperamos falhas com frequência, podemos nos importar muito com quanto tempo leva para recuperar. Ok, então essa é uma consideração. A outra consideração é que essa lacuna, ou seja, a lacuna esperada no tempo entre o primeiro timer disparar e o segundo timer disparar.

[1:03:03] Hum, essa lacuna realmente, para ser útil, tem que ser maior que o tempo que o candidato leva para reunir votos de todos. Ou seja... maior que o tempo de ida e volta esperado, a quantidade de tempo que leva para enviar um RPC e obter a resposta. Sim, talvez leve 10 milissegundos para enviar um RPC e obter uma resposta, obter uma resposta de, hum, todos os outros servidores. E se for esse o caso, precisamos fazer o máximo longo o suficiente para que seja bem provável que haja 10 milissegundos de diferença entre o menor número aleatório e o próximo menor número aleatório.

[1:03:35] Hum, obrigado. E para você, hum, o código de teste vai ficar irritado se você, uh, hum, obrigado, se você não se recuperar de uma falha de líder em alguns segundos. E então, de forma pragmática, você precisa ajustar esse máximo para baixo de modo que seja altamente provável que você consiga concluir uma eleição de líder em poucos segundos. Essa não é uma restrição muito apertada.

[1:04:09] Alguma pergunta sobre os timeouts de eleição? Um ponto pequeno é que, hum, você quer... Escolher novos timeouts aleatórios toda vez que houver, toda vez que você, toda vez que eu sei-- reinicia seu timer de eleição. Ou seja, não escolha um número aleatório quando... o servidor é criado pela primeira vez e depois reutilize esse mesmo número repetidamente. Porque você faz uma escolha azarada, ou seja, você escolhe o mesmo.

[1:04:39] um servidor por azar escolhe o mesmo número aleatório que outro servidor. Isso significa que você vai ter votos divididos repetidamente. para sempre. Então é por isso que você quer quase certamente escolher um diferente, um novo, um fresco aleatório para o valor de timeout de eleição toda vez que você reinicia o timer. Obrigado. Certo, então, uma questão final sobre eleição de líder. Suponha que estamos nessa situação em que o líder antigo está particionado.

[1:05:10] Sabe, o cabo de rede está rompido, e o líder antigo está meio que lá fora com alguns clientes. e uma minoria de servidores. Há uma maioria na outra metade da rede, e a maioria na nova metade da rede elege um novo líder. E o líder antigo? Por que o líder antigo não... Obrigado. causa execução incorreta. Obrigado. Talvez seja Sim, bem ali.

[1:05:56] É assim que vai... - Fico feliz em. Tchau. e está tudo feito. Deus. Obrigado. Sim. dois problemas potenciais. Ou um tipo de não-problema é que se há um líder em outra partição e ele não tem maioria, então na próxima vez que um cliente lhe enviar uma requisição, hum, esse líder que, sabe, uma abdicação com uma minoria, sim, ele enviará append entries, mas como está na partição minoritária, não conseguirá obter respostas de volta de uma maioria dos servidores, incluindo ele mesmo. E então ele nunca...

[1:06:34] commitar a operação, ele nunca a executará. Ele nunca responderá ao cliente dizendo que a executou também. E então isso significa que, sim, um servidor antigo em uma partição diferente as pessoas podem, os clientes podem enviar uma requisição, mas eles nunca receberão respostas. hum, então nenhum cliente será enganado a pensar que aquele servidor antigo executou qualquer coisa para ele. A outra questão mais complicada, que na verdade vou falar em alguns minutos, é a possibilidade de que antes de um servidor falhar, ele envie append entries para um subconjunto.

[1:07:14] dos servidores. e então trave antes de tomar uma decisão de commit. E essa é uma questão muito interessante, que hum provavelmente passaremos uns bons 45 minutos falando sobre isso. E então, na verdade, antes de eu voltar ao tópico em geral. mais perguntas sobre eleição de líder. Obrigado. OK. hum Ok, então e quanto ao conteúdo dos logs e como, em particular, um líder recém-eleito possivelmente juntando os cacos após um crash estranho do líder anterior, como um líder recém-eleito resolve os logs possivelmente divergentes nas diferentes réplicas?

[1:08:01] a fim de restaurar um tipo de estado consistente no sistema. Hum, certo, então a primeira pergunta é: o que pode, todo esse tópico só é realmente interessante depois que um servidor trava, certo? Se o servidor permanece ativo, então relativamente poucas coisas podem dar errado. Se temos um servidor que está ativo e tem uma maioria, sabe, durante o período em que está ativo e tem maioria, hum, ele apenas diz aos seguidores como o log deve ser.

[1:08:36] E os seguidores não têm permissão para discordar. Eles são obrigados a aceitar. Eles apenas fazem pelas regras da figura dois se estiverem mais ou menos acompanhando. Sabe, eles apenas pegam o que o líder lhes envia, e append entries, e anexam ao log, e obedecem às mensagens de commit, e executam. Quase nada dá errado. As coisas que dão errado no Raft dão errado quando o líder antigo trava meio que no meio, sabe, enviando mensagens ou um novo líder trava, sabe, logo depois de ser eleito, hum... antes de ter feito algo muito útil.

[1:09:08] Então, uma coisa que nos interessa muito é como os logs podem ficar após alguma sequência de crashes? Hum... Ok. Aqui está um exemplo. Então temos três servidores. Obrigado. Obrigado. Hum, e a maneira como vou desenhar esses diagramas, porque vamos olhar muitas, tipo, situações em que os logs ficam assim, e vamos nos perguntar: isso é possível, e o que acontece se ficarem assim? Então, minha notação vai ser, vou escrever entradas de log para, hum, cada um dos servidores meio que alinhadas para indicar slots.

[1:09:46] slots correspondentes no log. E os valores que vou escrever aqui são os números de termo em vez de operações de cliente. Vou, sabe, este é o slot um, este é o slot dois. Hum, todos viram um comando do termo três no slot um, Servidor 2 e Servidor 3 viram comando também do termo três, no segundo slot, o servidor um não tem nada lá. Hum, e então a pergunta para isso, tipo a primeiríssima pergunta é: isso pode surgir?

[1:10:18] Isso poderia... configuração surgir e como? Oh. Como? Obrigado. Sim, então. Obrigado. Então.

[1:11:03] Então talvez o servidor três fosse o líder por, apenas repetindo o que você disse, talvez o servidor três seja o líder do termo três. Ele recebeu um comando que enviou para todos. Todos receberam o dependente como o log. E então eu tenho um servidor três, recebeu uma segunda requisição de um cliente. e talvez tenha enviado para todos os três servidores, mas a mensagem se perdeu no caminho para o servidor um, ou talvez o servidor um estivesse inativo na época ou algo assim, e então apenas o servidor dois Bem, o líder sempre anexa novos comandos ao seu log antes de enviar append entries. Hum, e talvez o RPC de append entry só tenha chegado ao servidor dois. Então essa situação, sabe, é tipo a situação mais simples em que na verdade os logs agora estão diferentes.

[1:11:38] E sabemos como isso poderia possivelmente... surgir. E então se o servidor três, que é o líder, travar agora, sabe, o próximo servidor eles vão precisar garantir que o servidor um Bem, primeiro de tudo, se o servidor 3 travar, ou tivermos uma eleição e algum outro líder for escolhido, sabe, duas coisas têm que acontecer. O novo líder... Ele tem que reconhecer que Isso. Hum, um comando pode ter sido commitado. Ele não tem permissão para descartá-lo. e ele precisa garantir que o servidor um preencha este espaço em branco aqui com de fato este mesmo comando que todos os outros tinham naquele slot.

[1:12:15] Hum, obrigado. Certo, então após um crash, alguém, sabe, um servidor suponha, outra maneira de isso surgir é que o servidor três pode ter enviado os append entries para o servidor dois, mas então travou antes de enviar os append entries para o servidor três. Então, se estamos elegendo um novo líder, pode ser porque tivemos um crash. antes da mensagem ser enviada. Certo, aqui está outro cenário para pensar. Hum, três servidores de novo. Obrigado. Obrigado. Obrigado. Hum, agora vou numerar os slots no log.

[1:12:47] Para que possamos nos referir a eles. Hum, temos o slot 10, 11, 12. Obrigado. 13. De novo. Isso é... Obrigado. mesma configuração exceto que agora temos no slot 12, temos o Servidor 2 como um comando do termo quatro e o servidor três tem um comando de termo do termo cinco. Obrigado. Obrigado. Então-- Antes de analisarmos isso para descobrir o que aconteceria, o que um servidor faria se visse isso, precisamos perguntar: isso poderia sequer ocorrer?

[1:13:25] Às vezes a resposta à pergunta, ah nossa, o que aconteceria se essa configuração surgisse? Às vezes a resposta é: isso não pode surgir, então não precisamos nos preocupar com isso. hum Então a pergunta é: isso poderia surgir e como? Sim. diga não, porque temos muitos. Ok. Obrigado. Obrigado. Hum, certo.

[1:14:00] E qualquer-- Certo. Obrigado. A primeira situação acontece. Amém. assistindo. amigos. - Agora, Troy. Tchau. Roger. Obrigado. O quê? Uh... Certo, sensei.

[1:14:32] pessoal. Obrigado. - Oh meu Deus. Certo. voltar. Sim. Até onde? Então deixe-me apenas repetir isso. Breve. sabemos que essa configuração pode surgir, e então a maneira como podemos obter um quatro e um cinco aqui é, suponhamos que na próxima eleição de líder, o servidor 2 seja eleito líder.

[1:15:09] Agora para o termo quatro. Eleja o líder. Você recebe uma requisição de um cliente, ele a anexa ao seu próprio log e trava. Então agora temos isso. Certo, precisamos de uma nova eleição porque o líder acabou de travar. Agora, nesta eleição, obrigado. E então agora temos que perguntar quem poderia ser eleito, ou temos que manter no fundo da mente, ah nossa, quem poderia ser eleito? Hum, então vamos afirmar que o servidor três poderia ser eleito. A razão pela qual ele poderia ser eleito é porque ele só precisa de respostas de request vote de uma maioria. Essa maioria é o servidor um e o servidor três.

[1:15:41] Você sabe, não há problema, nenhum conflito entre esses dois logs. Então o servidor três pode ser eleito para o mandato cinco, receber uma requisição de um cliente, anexá-la ao seu próprio log e travar. E é assim que você chega a esta, uh, configuração. Então você precisa ser capaz de-- Tchau. de trabalhar através dessas coisas. para chegar ao estágio de dizer, sim, isso poderia acontecer, e portanto, o Raft deve fazer algo sensato, em oposição a, isso não pode acontecer. Porque algumas coisas não podem acontecer.

[1:16:12] Um, Obrigado. Certo, então... Um, Então o que pode acontecer agora? Sabemos que isso pode ocorrer. Esperançosamente podemos nos convencer de que o Raft realmente faz algo sensato. Agora, quanto à gama de coisas, antes de falarmos sobre o que o Raph realmente faria. Precisamos ter alguma noção do que seria um resultado aceitável.

[1:16:47] Certo? e apenas olhando isto, Um, Sabemos que o comando no slot 10, uma vez que é conhecido por todas as réplicas, poderia ter sido confirmado. então não podemos descartá-lo. Similarmente, o comando no slot 11, uma vez que está na maioria das réplicas, poderia, pelo que sabemos, ter sido confirmado, então não podemos descartá-lo. O comando no slot 12, no entanto, nenhum deles poderia possivelmente ter sido confirmado. Então temos o direito. Não sabemos, não olhamos para o que o Raft realmente fará, mas o Raft tem o direito de descartar ambos, embora não tenha o direito de descartar nenhum dos comandos no 10 ou 11.

[1:17:26] Um, Este é um descarte permitido. Não é obrigatório descartar qualquer um deles. E sabemos que certamente deve descartar um, pelo menos um, porque você tem que ter conteúdos de log idênticos no final. Isto poderia ter sido confirmado. o Não podemos dizer olhando os logs exatamente até onde o líder chegou antes de travar. Então uma possibilidade é que, para este comando ou mesmo este comando, uma possibilidade é que um líder enviou as mensagens de append com um novo comando e então imediatamente travou.

[1:18:04] Então nunca recebeu nenhuma resposta de volta porque travou. Então o antigo líder não sabia se estava confirmado. E se não recebeu uma resposta de volta, isso significa que não o executou e não enviou, mas, você sabe, não enviou o índice de confirmação incrementado. E então talvez as réplicas também não o executaram. Então é realmente possível que isto não tenha sido confirmado. Então, Mesmo que o Raft não saiba, Um, Poderia ser legal para o Raft Obrigado.

[1:18:36] Se o RAP soubesse mais do que sabe, Poderia ser legal descartar esta entrada de log, porque pode não ter sido confirmada. mas porque com base nas evidências, Não há maneira de refutar que foi confirmada com base nestas evidências. Poderia ter sido confirmada. e o Raft não pode provar que não foi. Então deve tratá-la como confirmada. Certo, porque o líder pode tê-la recebido, pode ter travado logo após receber as respostas de append entry. e responder ao cliente. Então, apenas olhando para isto, não podemos descartar a possibilidade de qualquer uma das possibilidades.

[1:19:11] que o líder respondeu ao cliente, caso em que não podemos descartar esta entrada porque um cliente sabe sobre ela. Ou a possibilidade de que o líder nunca o fez, e sim, poderíamos. você sabe Então temos que assumir que foi confirmada. Pergunta? . um, Uh...

[1:19:46] Não, não há--Quero dizer, nesta situação, talvez o servidor tenha travado antes de receber o Certo, vamos continuar isto. na quinta-feira.