Vamos avançar mais sobre como os bancos de dados distribuídos atuam sobre os desafios de comunicação e comportamento dos seus nós-membros. E com isso, nós vamos chegar no assunto de replicação. Para abordarmos a replicação, precisamos falar de alguns fundamentos desse assunto. Então, vamos começar essa jornada. Aqui, antes de mais nada, preciso fazer um comentário com você sobre relógios e tempo sobre o contexto dos sistemas distribuídos. E aqui estamos estamos falando pensando em bancos no ciclo e news ficou que são bancos de dados que atuam de maneira distribuída vamos lá medir o tempo é algo necessário em sistemas distribuídos para que os agendadores de tarefas consigam atuar para que os temporizadores tenham as suas ações realizadas sejam por timeout ou por retry, retentativas. Nós já vimos que na gestão de transações distribuídas, o tema de timeout e retentativa é muito importante. Principalmente, também vimos na última discussão sobre a detecção de falha, que é algo importante, os nós componentes de um sistema distribuído precisam ter a capacidade de detecção de falha, que é algo importante. Os nós componentes de um sistema distribuído precisam ter a capacidade de detecção de falha e essa capacidade está muito relacionada ao tempo. Medição de desempenho, rastreabilidade de ações executadas, dados com validade temporal e nós vamos chegar numa questão que determinar a ordem de ocorrência dos eventos em múltiplos nós é muito importante. E com isso, nós vamos entender que temos alguns tipos de relógio. Primeiro, relógio físico é a contagem do número de segundos decorridos. é a contagem do número de segundos decorridos. E isso não é a mesma coisa que um relógio lógico, que é a contagem de eventos ou mensagens que aconteceram e foram enviados. Especificamente para o tema de relógio lógico, nós temos o relógio de Lamport, que vai nos permitir entender a ordem causal de eventos, e os relógios baseados em vetores, o relógio vetorial, que detecta eventos concorrentes. Sabendo dessas possibilidades e formas de perceber o tempo, e formas de perceber o tempo, seja ordem de eventos, que é o principal fato para a gente chegar na consistência num sistema distribuído, nós vamos ter também o tema de transmissão ou multitransmissão, ou broadcast, que basicamente é uma comunicação em grupo, um grupo de nós que constituem aquele banco de dados distribuído. Um nó envia mensagens e todos os nós entregam essas mensagens aos nós seguintes. Os membros do grupo podem ser estáticos ou dinâmicos, ou seja, ao longo do ciclo de vida desse banco de dados distribuído, mais nós podem ser adicionados ou podem ser perdidos durante esse ciclo de vida. Então, a entrega ou a transmissão, melhor palavra aqui, a transmissão dessas mensagens, pode acontecer de duas formas. Melhor esforço ou best effort, ou seja, os nós mandam para frente as mensagens, porém algumas mensagens podem ser perdidas. Ou a transmissão pode ser confiável ou reliable. Todas as mensagens são transmitidas daquele nó para os nós seguintes. Então, aqui nós vamos perceber que o nó A vai ter a sua aplicação emitindo uma mensagem, ou seja, uma transmissão de mensagem, operação de broadcast, e essa operação está sujeita a um algoritmo de transmissão. Este algoritmo vai fazer a interação com a camada de rede, enviando e recebendo mensagens. Para o nó B receber, o algoritmo de transmissão vai realizar uma operação de entrega dessa mensagem que foi originada no nó A. Então, nós vamos ter algumas formas de transmissão confiável, reliable broadcast, para que aquela transmissão tenha a respectiva entrega acontecendo do nó A para o nó B. Então, primeira maneira, SIFO broadcast. SIFO vem de first in, first out. Então, vamos traduzir isso como transmissão, primeiro que entra, primeiro que sai. Então, se a mensagem 1 e 2 são transmitidas pelo mesmo nó A e a transmissão da mensagem número 1 precede a transmissão de M2, ou seja, aconteceu antes, então M1 tem que ser entregue antes de M2 no nó que está recebendo essa informação. Então vamos levar o nosso diagrama, o nó A faz a transmissão, o nó B tem a entrega. Então o FIFO Broadcast fala que se M1 e M2 estão sendo transmitidas do mesmo nó e a transmissão de M1 aconteceu antes de M2, então M1 tem que ser entregue antes de M2 no nó B. Causal broadcast ou transmissão causal. Aqui a regra nos diz que se a transmissão de M1 precede a transmissão de M2, então M1 tem que ser entregue antes de M2, independente do nó onde isso aconteceu. Aí nós vamos ter Total Order Broadcast, ou transmissão de ordem total. ou transmissão de ordem total. Se M1 é entregue antes de M2 em um nó, então M1 tem que ser entregue antes de M2 em todos os nós. Perceba que aqui estamos falando da operação de entrega, e não da operação de transmissão. E por fim nós temos a combinação do FIFO com o Total Order Broadcast, que é o FIFO Total Order Broadcast. Então nós temos essas quatro formas de transmissão do tipo confiável, que é aquela transmissão que todas as mensagens são repassadas para os nossos participantes. repassadas para os nossos participantes. E olhando de uma maneira geral, nós vamos perceber que na transmissão de melhor esforço, Best Effort Broadcast, vai ficar na base desse diagrama, ou seja, é o protocolo mais fraco. Então, o Reliable Broadcast é mais forte que o Best Effort Broadcast, o FIFO Broadcast é mais forte que o Reliable Broadcast é mais forte que o Best Effort Broadcast, o FIFO Broadcast é mais forte que o Reliable, Causal é mais forte que o FIFO, e aí no topo nós vamos encontrar o Total Order Broadcast, que é mais forte que o Reliable Broadcast, e a combinação de ambos chega no FIFO Total Order Broadcast. Vamos prestar atenção principalmente no Total Order Broadcast, porque nós veremos logo em seguida que o assunto de replicação está intimamente ligado com este conceito. Replicação. Replicação é manter uma cópia dos mesmos dados em múltiplos nós. Um nó com uma cópia de dados é chamado de réplica. Estas réplicas podem ter algumas réplicas indisponíveis, enquanto outras estarão acessíveis, disponíveis. A replicação também vai nos permitir distribuir uma carga de trabalho sobre muitas réplicas Ou seja, teremos ali um paralelismo de operações de leitura, por exemplo, acontecendo E a replicação acaba sendo um conceito muito fácil quando os dados são estáticos Ou seja, é uma mera cópia É claro que na vida real nós não trabalhamos somente com dados estáticos. A maioria das operações está relacionada a dados dinâmicos, dados em movimento. Então, por isso, nós precisamos para a replicação ter um foco na mudança dos dados. O data change, que é muito discutido em diferentes arquiteturas. E aqui nós vamos concluir o seguinte, a replicação baseada em total order broadcast é amplamente utilizada em sistemas distribuídos e consequentemente está presente nos bancos de dados distribuídos, nos NoSQL e NoSQL que buscarão essa implementação de alguma maneira. Vamos observar neste exemplo que nós temos o cliente número 1 iniciando uma transação e essa transação já é iniciada no nó líder. Então aqui nós já percebemos que a organização dos nós com um nó líder e demais nossos seguidores é algo que faz parte dessa abordagem de replicação que é baseada em Total Order Broadcast. 1 no líder, cliente 2 inicia uma transação neste mesmo líder, essa transação 2 termina antes que a 1, é comitada no seguidor, a resposta do líder retorna para o cliente número 2, então transação 2 executada com sucesso e logo depois a transação 1 é concluída com sucesso também, então acontece o commit no seu seguidor e o ok para o cliente número 1. Então, este diagrama, que é algo que a gente vive com muita frequência quando está trabalhando com MongoDB ou com bancos distribuídos, tem como fundamento este conteúdo inicial de replicação baseada em Total Order Broadcast.