Os bancos de dados Redis podem armazenar objetos pequenos, de curta duração e complexos que persistem por meses. Independentemente da complexidade e tamanho dos objetos, a disponibilidade contínua desses dados é uma obrigação para fornecer serviço de back-end contínuo ao cliente.Geralmente, a instalação independente de redis é fácil de configurar e utilizar. Mas não é a melhor opção para usar em um ambiente em que as falhas do nó possam ocorrer. A durabilidade dos dados pode ser retida com o recurso Redis Append Soly File (AOF) no Redis, mas não é a solução ideal para alta disponibilidade. Da mesma forma, os arquivos Redis RDB podem ser usados ​​como uma opção de backup, que é uma representação ponto-in-time dos dados. Ambas as opções não abordam o problema das falhas repentinas do nó redis.Assim, Redis introduziu vários recursos internos para suportar a alta disponibilidade de bancos de dados Redis discutidos na seção a seguir.

Replicação do banco de dados

A replicação do banco de dados é a técnica fundamental por trás de disponibilizar um sistema de banco de dados e continuamente disponível. A replicação copia dados do banco de dados Master (banco de dados primário) para um ou mais bancos de dados de escravos (réplicas) que garantem que os dados sejam acessíveis a qualquer momento se um nó mestre falhar. Este processo é acoplado a um processo automático de failover que promove um novo mestre dos nós de réplica disponível quando o nó mestre falha.

Replicação de Redis construída

Redis começou a apoiar a replicação de suas primeiras versões e melhorou imensamente. A versão independente suporta replicação básica com o comando escravo, convertendo um nó existente em um escravo do nó principal do banco de dados. Além disso, o recurso Redis Sentinel permite replicação com um recurso de failover mais avançado. Além disso, o cluster Redis suporta um rico conjunto de recursos de alta disponibilidade para sistemas de banco de dados mais distribuídos e grandes.

Replicação básica de redis com comando escravo

Uma das maneiras fundamentais de alcançar a replicação Redis é usando o comando escravo.

Está a um passo de fazer de uma instância Redis um nó escravo. A linha a seguir deve ser adicionada ao arquivo de configuração da instância específica:

escravo

Caso de uso

O exemplo a seguir demonstra um cenário em que uma determinada instância de Redis é configurada para ser um nó escravo de um nó mestre que é executado nos 127.0.0.1 endereço na porta 7000.

Com essa configuração, o banco de dados mestre copiará todos os dados para o nó escravo, que garante que o escravo seja uma cópia exata do nó do banco de dados primário.

Uma vez que o nó mestre está em funcionamento a 127.0.0.1 e porta 7000, vamos iniciar a outra instância cujo arquivo de configuração contém a configuração de escravos. A nova instância será executada na porta 7001.

A nova instância é iniciada com sucesso e sincronizada com o Master Runs às 127.0.0.1 (porta 7000).

Se você escrever alguns dados para o nó principal, eles podem ser lidos pelo escravo da seguinte forma. Isso significa que mestre e réplica foram sincronizados adequadamente.

Escrevendo dados para o nó principal é executado na porta 7000 da seguinte forma.

Lendo dados do nó escravo é executado na porta 7001, como mostrado no seguinte:

Com essa configuração, quando o Redis Master falha, já temos uma cópia exata do banco de dados primário em execução na porta 7001. Da mesma forma, você pode configurar vários escravos para um determinado nó mestre. A única desvantagem nessa configuração é que você precisa cuidar manualmente do processo de failover.

Prós

• Fácil e menos demorado para configurar.
• Esta configuração funcionará enquanto um único nó principal estiver disponível e mesmo sem um único nó de escravo.
• Possível automatizar com ferramentas de gerenciamento de configuração.

Contras

• O processo de failover principal não é automatizado.
• Como as leituras são assíncronas, leituras obsoletas podem ocorrer.
• A utilização de mestre e escravo não é igual devido ao sharding não é suportado.

Alta disponibilidade com Redis Sentinel

Redis Sentinel foi apresentado para lidar com as desvantagens da solução anterior. Redis Sentinel é um sistema distribuído que atua como uma solução avançada de alta disponibilidade para Redis, juntamente com outros recursos, como provedor de notificação, ferramentas de monitoramento e provedor de configuração para clientes.

O Sentinel é capaz de promover um escravo para um nó mestre automaticamente sem qualquer intervenção humana. O processo de failover principal inicia se o número máximo especificado de nós sentinel (quorum) concordar que o nó principal não estiver alcançável. Então, a disponibilidade dos nós sentinel é importante. No entanto, é recomendável usar um cluster Sentinel separado para executar nós do Sentinel separadamente dos nós mestre. Com esta configuração, os clientes Redis falam primeiro com o nó Sentinel e solicitam informações sobre o nó mestre atualmente em execução. Então apenas os clientes trabalharão com o mestre atual.

É possível iniciar um servidor Redis no modo Sentinel, como mostrado no seguinte comando:

Redis-Server --sentinela

Conforme mostrado na saída a seguir, o servidor foi iniciado no modo Sentinel.

Além disso, os Redis Sentinels também podem ser colocados com os servidores Redis.

Prós

• Recurso de failover automático
• Simples e menos demorado para configurar

Contras

• Sentinel precisa de um cluster separado se não for colocado com os nós do servidor Redis
• A utilização de nós mestre e escravo está desequilibrada devido a nenhuma opção de sharding disponível
• Redis Sentinel é um sistema distribuído e envolve uma quantidade considerável de manutenção

Alta disponibilidade com cluster de redis

Com os lançamentos mais recentes do Redis, um componente de cluster foi adicionado à pilha Redis. Ele suporta:

• Sharding
• Replicação
• Alta disponibilidade

Portanto, o cluster Redis aborda vários aspectos que estão faltando em soluções anteriores. Tornou -se extremamente benéfico para grandes empresas que geram e armazenam uma grande quantidade de dados. Porque o sharding distribui seus dados entre vários mestres, cada um com um subconjunto de todo o espaço chave. Isso lhe dá um grande impulso de desempenho.

Ao mesmo tempo, a replicação está disponível em clusters Redis, onde você pode configurar vários nós de escravos para um determinado mestre. Geralmente, um nó de cluster deve conter exatamente uma instância do servidor Redis. Mas é possível configurar a replicação cruzada implantando várias instâncias em um único nó.

Além disso, a opção de failover automática é fornecida pelos clusters Redis, onde o nó escravo promoverá para um mestre. Em uma configuração de cluster, o quorum não é obrigado a promover um novo nó mestre ou sharding para funcionar. O quorum mestre do nó é necessário apenas para todo o cluster executar.

Portanto, a solução Redis Cluster pode ser vista como uma solução tudo em um para aqueles que procuram sharding, replicação e alta disponibilidade em suas aplicações.

Prós

• Suporta Sharding, o que dá um impulso ao desempenho ao consultar o Redis Data Store.
• Fornece solução de failover automática
• Suporte de Mestre-Replica

Contras

• Manter um cluster pode ser uma quantidade considerável de trabalho
• Falta de suporte da biblioteca

Conclusão

Redis suporta alta disponibilidade com redis independente, modelo Redis Sentinel e componente de cluster embutido. Todas as três soluções têm seus prós e contras, conforme discutido acima. No geral, o Redis Sentinel é a opção preferida se você estiver procurando apenas alta disponibilidade e não se preocupa com o desempenho. Mas se você está procurando um equilíbrio entre desempenho e alta disponibilidade com replicação cruzada, sem dúvida, o cluster Redis é o melhor entre os três.