Redis Sentinel vs Cluster

Redis Sentinel vs Cluster

Redis pode ser identificado como um servidor de dicionário remoto que é projetado principalmente para velocidade. Além disso, é amplamente utilizado como um cache na memória e um banco de dados NoSQL. Como banco de dados ou cache, é vital fornecer uma alta taxa de acesso a dados, alta disponibilidade, sharding de dados e recursos de escalabilidade. Redis introduziu soluções Sentinel e Cluster para abordar os aspectos mencionados.

Cluster Redis

A tecnologia Redis Cluster que foi introduzida na versão 3.0 Ativa a escala horizontal para uma determinada implantação de Redis. Com os clusters Redis, os dados são divididos em vários nós de cluster que fornecem uma camada de serviço de dados consistente e confiável para aplicativos.

É essencial ter pelo menos três nós mestre para um cluster funcionar corretamente. Além disso, cada nó principal deve ter pelo menos um único nó de escravo. Além disso, os clusters Redis permitem alta disponibilidade até certo ponto, promovendo um nó escravo associado a uma instância mestre com falha em um hardware/software ou falha de rede.

Cada nó de cluster se comunica com outros nós usando um canal de comunicação de nó-nó baseado em protocolo binário. Além disso, cada nó está aberto às conexões do cliente, utilizando a porta TCP padrão.

A seguir, é apresentado um esboço de alto nível de uma configuração básica de cluster Redis:


Prós:

  • Sharding de dados
    • Os dados são compartilhados entre vários nós e podem ser ajustados dinamicamente.
    • Como não há centro de controle central, os dados são divididos entre os nós automaticamente.
  • Escalabilidade
    • Um cluster pode escalar até 1000 nós. Nós podem ser removidos ou adicionados dinamicamente.
  • Failover automático
    • O Redis Cluster suporta a arquitetura mestre-escravo e permite a técnica de failover mestre embutida.


Contras:

  • Não está completamente disponível
    • No caso de uma grande falha, a maioria dos nós mestres pode cair, o que faz com que todo o cluster caia.
  • O alto número de nós por cluster único
    • É necessário ter pelo menos três instâncias mestres e um único nó escravo por mestre, que acaba com seis nós para configurar um cluster Redis funcionando corretamente.
  • Sem garantia de consistência dos dados
    • A replicação mestre do cluster Redis é processada de forma assíncrona e pode afetar a consistência.
  • Falta de suporte da biblioteca de clientes para o cluster Redis
    • Há um número mínimo de bibliotecas de clientes que suportam as implementações do Redis Cluster.
  • Replicação de camada única
    • A arquitetura Redis Cluster Master Replicação permite apenas uma única camada. Uma determinada instância de escravo pode replicar apenas o nó principal.
  • Redis Cluster pode perder gravações reconhecidas em alguns cenários
  • O manuseio de dados é mais complicado
    • Devido ao sharding de dados, os administradores de cluster devem gerenciar vários arquivos RDB e AOF. Além disso, é necessário um esforço extra para agregar arquivos de persistência de vários nós para fazer um backup.

Redis Sentinel

Redis Sentinel é uma abordagem de alta disponibilidade para implantações de Redis que é executada como um programa separado em segundo plano. Ele traz muitos recursos para suas implantações Redis, constantemente verificando o status de mestre e nó escravo, notificando as mudanças significativas relacionadas às instâncias monitoradas por meio de uma API, inicializando o processo automático de failover quando uma falha mestre ocorre e agindo como uma fonte de fonte de Autoridade para os clientes descobrirem o endereço IP do nó mestre do Redis atualmente ativo.

Uma configuração Redis Sentinel pode ser implementada usando pelo menos três nós sentineados, o que pode evitar a maioria dos problemas em uma determinada implantação de Redis. Além disso, em uma determinada configuração Sentinel, o valor do quorum define o número mínimo de nós sentineados que devem confirmar quando um mestre é falhado.

Geralmente, o Redis Sentinel é empregado principalmente para apoiar a alta disponibilidade de um banco de dados Redis, onde funciona melhor do que na abordagem de agrupamento.

A seguir, é apresentada uma ilustração de alto nível de uma configuração mínima de Redis Sentinel:


Prós:

  • Número mínimo de nós
    • Uma implantação de Sentinel Redis completamente funcionando pode ser formada com três nós.
  • Altamente disponível
    • A implantação do Redis Sentinel pode sobreviver a falhas críticas do nó sem qualquer intervenção humana.
    • Ele pode funcionar quando pelo menos uma única instância mestre está disponível, embora cada escravo esteja abaixo.
  • Replicação mestre aprimorada
    • Na implantação de Redis Sentinel, vários escravos podem replicar uma determinada instância mestre.
  • Simplicidade e flexibilidade
    • Redis Sentinel é muito fácil de manter e tem opções de configuração flexíveis também.


Contras:

  • Nenhum rastro apoiado
    • O empate de dados não é possível. Portanto, os conjuntos de dados em larga escala acessibilidade podem causar a degradação do desempenho.
  • Falta de escalabilidade
  • Leituras desatualizadas
    • Geralmente, os nós escravos servem leituras na implantação de Redis Sentinel. Devido à replicação assíncrona, as leituras podem não estar atualizadas.
  • Redis Sentinel deve ser suportado pela biblioteca de clientes
  • O nó escravo não atua como um nó de backup

Redis Sentinel vs Cluster

Redis Cluster e Sentinel são duas abordagens em que cada um aborda diferentes aspectos relacionados a uma implantação Redis. Para destacar, a abordagem do cluster Redis é mais adequada para implementações complicadas que lidam com conjuntos de dados maciços, onde fornece um sharding de dados automático para obter melhor desempenho de consulta de leitura/gravação, failover mestre automático e replicação com alta disponibilidade até certo ponto. Além disso, os nós do cluster Redis podem ser escalados sem esforço.

Por outro lado, o Redis Sentinel está mais focado em implementações menores com alta disponibilidade em mente.

Disponibilidade

O cluster Redis não suporta totalmente a alta disponibilidade. Porque, se a maioria dos mestres não estiver disponível, o cluster pode cair. Em contraste com a abordagem do cluster, o Redis Sentinel oferece alta disponibilidade sem qualquer intervenção humana. Mais importante ainda, o Sentinel pode sobreviver mesmo com uma única instância mestre em execução quando uma falha crítica ocorre.

Sharding de dados

O Redis Cluster oferece recursos de fragmentação, onde os dados são distribuídos entre vários nós quando os clientes têm acesso à rede a todos os nós. Permite maior capacidade de desempenho e armazenamento de dados.

Por outro lado, o Redis Sentinel não oferece recursos de fragmentação. Porque o sharding causa a utilização do desequilíbrio do mestre e escravo.

Replicação

Ambas as abordagens oferecem replicação mestre com algumas limitações. Redis Sentinel permite replicação para várias camadas, onde vários nós de escravos podem replicar de uma determinada instância mestre. Por outro lado, a abordagem do cluster Redis não permite replicação para várias camadas. É capaz apenas de replicar a instância mestre em um único nó de escravo. Ambas as abordagens comprometem a consistência devido à replicação assíncrona.

Escalabilidade

Clusters Redis são altamente escaláveis. Ele suporta até mil nós em uma determinada configuração de cluster único. Além disso, os clusters permitem adicionar e remover os nós dinamicamente e sem esforço. Redis Sentinel não é escalável e as gravações são direcionadas para a instância mestre, portanto, o Sentinel não pode lidar com os problemas de separação de leitura e gravação.

Arquitetura

Um Redis Sentinel totalmente funcional pode ser construído com apenas três nós. Mas para configurar um cluster Redis, requer pelo menos três nós mestres e três escravos anexados a eles, o que é mais caro do que na implantação de Redis Sentinel.

Conclusão

Para resumir, a abordagem do cluster Redis está mais focada em implantações complexas quando alta escalabilidade, alto desempenho e alto armazenamento de dados são importantes e a alta disponibilidade não é significativa. Por outro lado, o Redis Sentinel é construído principalmente para aplicações simples que são focadas principalmente na alta disponibilidade. Em comparação, ambas as soluções vêm com seus prós e contras, mas para apoiar os usuários finais com implantação Redis mais ajustada.