Olá a todos! Estou aqui novamente para compartilhar mais do que aprendi esta semana, especificamente sobre o tema da replicação de dados. Este artigo fornecerá uma explicação resumida do que é e quais são os seus tipos. Vamos lá!
Por Que a Replicação de Dados é Importante?
Para entender a importância da replicação de dados, considere este cenário: Imagine que este é um servidor hospedado na minha casa. Se eu acidentalmente derramar café em cima do servidor/DB, o que acontece? Já era.
Temos aqui um "Single point of failure".
Outro ponto é que usuários de países diferentes têm tempos de resposta diferentes. Dependendo da localização, demora um tempo considerável para obter resposta da aplicação, o que pode prejudicar a experiência do usuário.
Então, a replicação pode servir para, caso algum servidor deixe de funcionar, aumentar a disponibilidade e diminuir a latência para diferentes localidades. Adicionamos mais DBs para poder garantir essas melhorias.
Porém, não sei se vocês notaram, mas surge um novo problema: Temos 3 bancos de dados em 3 lugares diferentes. Como garantir e manter a sincronização entre os 3 bancos de dados?
Abordagens para Consistência de Dados
Ao lidar com múltiplos bancos de dados, garantir a consistência dos dados é crucial. Existem duas abordagens principais:
1. Replicação Síncrona
A primeira abordagem é a Síncrona. Ela garante o dado mais recente (tendo uma consistência forte) através de fazer com que o usuário aguarde, se necessário, todo o processo de replicação para obter a resposta dele. O problema dessa abordagem é que ela gera uma certa lentidão.
![Sincrona]https://pbs.twimg.com/media/GpI_d8sWsAAYR5J?format=jpg&name=4096x4096)
2. Replicação Assíncrona
A outra abordagem é a Assíncrona. Com ela, o usuário não precisa esperar todo o processo de replicação (pois ele é feito em background), o que torna o acesso ao dado mais rápido. Seu problema é que não garante que a consistência seja 100%, e sim a chamada "consistência eventual".
Métodos de Replicação
Agora que vocês sabem as abordagens, vamos para os métodos de replicação. Vou apresentar 3:
- Single-leader replication
- Multi-leader replication
- Leaderless replication
1. Single-Leader Replication
No Single-leader replication, apenas um banco recebe os writes e replica para os outros que apenas recebem reads.
- Prós: É bom pois não tem conflitos.
- Contras: Porém, tem um Throughput baixo e possui Single point of failure pois só um escreve.
-
Caso de Uso: É comum de ser usado em aplicações financeiras.
2. Multi-Leader Replication
Já o Multi-leader replication, a replicação de dados ocorre entre os DBs, ou seja, todos são líderes.
- Prós: Possui um alto throughput para escritas.
- Contras: O que pode gerar conflitos nas escritas.
-
Caso de Uso: É usado para grandes áreas geográficas.
3. Leaderless Replication
Por fim, o Leaderless replication funciona na forma de "Quorum" para lidas e escritas. Para simplificar, veja a imagem abaixo: Temos 4 nós, se um user quiser ler/escrever, será lido um pouco a mais da metade do número de nós para assim ter a resposta.
- Prós: Isso é feito para garantir a consistência, o que gera uma alta disponibilidade.
- Contras: Porém, acaba causando conflitos de escrita e gera latência na leitura.
-
Caso de Uso: É usado em sistemas que priorizam alta disponibilidade e tolerância a falhas, como sistemas de mensagens.
Conclusão
Bom, é isso. Espero que minha explicação tenha sido clara. Caso queiram, eu posso aprofundar mais em consistência e como lidar com conflitos de escrita. Fiquem livres para adicionar o que acharem relevante!
Obrigado por lerem até aqui!
Recomendo se aprofundarem em cada um deles, dei apenas uma visão geral e superficial para compreensão geral. Alguns materiais para leitura que dão uma complementada legal:
Top comments (0)