Redis - entendendo e configurando, com high availability (HA)

otavio publicou em 28/01, 02:49 hs , e editou pela última vez há mais de 3 anos atrás.

O Redis é um banco de dados do tipo par de chaves e valores. Sua principal característica é a velocidade de acesso e gravação. Isso por ser, basicamente um banco em memória. Mas isso é outras coisas já foram explicadas em outro post.

Ser um banco em memória não quer dizer que não há persistência de dados (como pode ser visto aqui ). O que acontece é que o Redis salva as transações em um formato append only e, quando o tamanho do arquivo cresce muito, ele cria um dump da base e volta ao modelo append only.

A diferença para um servidor RDBMS é que um RDBMS volta para o ar mais rápido, apesar do tempo de resposta em um primeiro momento ser muito ruim. Enquanto o Redis lê todo o log e levanta a base antes de voltar a aceitar conexões.

Como todos os melhores servidores NoSQL, a replicação é algo nativo (sem plugins externos). E também é rápida a replicação. Muito rápida. Melhor ainda é que a detecção de servidores na mesma rede é algo simples.

O Redis pode operar com vários servidores, mas apenas um master (o outro ou os outros são slave). Mas ele permite a partição de dados de forma simples. Dessa forma, mais de um servidor passa a responder como master, mas com divisão da massa de dados. Mais recentemente foi criado também o Redis Cluster que permite dividir a carga de registros entre um conjunto de nós de servidores. A especificação completa é bem interessante de ler. A maior virtude é não ser simplesmente um sharding, mas sim um ambiente de gerenciamento dessas partições, podendo adicionar e remover nós da rede. O Redis Cluster ainda não é considerado “production ready” e por isso não vou tratar dele aqui.

A terceira forma, chamada na própria Redis de ambiente de “alta disponibilidade”, é o Sentinel. Ele é uma evolução do modelo master/slave. Ele possui internamente uma estrutura de monitoramento, notificação (através de chamadas de APIs) e faillover automático. É sobre ele que falaremos aqui.

A estrutura do Sentinel necessita de 2 ou mais máquinas servidoras (no mínimo um master e um slave) e quantos Sentinel você quiser. Na Fidelize usamos 3 servidores desse (ou agentes se preferir). Cada Sentinel tem o trabalho de enxergar as conexões de rede e entender se a operação está ativa ou não. Não vou explicar todos os passos que estão muito bem explicados na documentação, mas o que o Sentinel faz é entender se o master está ou não operando e, se ele(s) enxerga(m) que o master não está operando de forma adequada, elege(m) um novo master entre os servidores existentes na rede.

As principais vantagens, a meu ver, em relação ao uso de um ambiente de High Availability (HA) comum:

  • Ao invés de termos apenas um master e um slave, podemos ter quantos servidores quanto necessários
    • Na Fidelize, por exemplo, por operarmos com vários data centers, temos um slave em cada data center de modo a permitir o HA geográfico se necessário.
  • Como as conexões passam pelo Sentinel para validar o master, no caso do antigo master retornar a rede, o mesmo é demovido automaticamente e passa a receber as replicações.

A configuração é bem simples do ambiente. Um exemplo pode ser visto abaixo. Estou mostrando apenas o que mudei em relação à configuração padrão.

Server 1:

port 6379
bind 127.0.0.1

Server 2:

port 6380
bind 127.0.0.1
slaveof 127.0.0.1 6379

Sentinel:

# redis-sentinel.conf 
daemonize yes
pidfile /var/run/redis/redis-sentinel.pid

sentinel monitor the_one 127.0.0.1 6379 1
sentinel down-after-milliseconds the_one 30000
sentinel failover-timeout the_one 180000
sentinel can-failover the_one yes
sentinel parallel-syncs the_one 1

Por padrão, os Redis se acharão na rede e, por estar configurado para o 127.0.0.1:6379 ser o servidor master, o mesmo assumirá o serviço, com o 127.0.0.1:6380 passando para slave. Se o serviço estiver ativo e o master cair, o Sentinel elegerá o 6380 como novo master.

Você pode verificar usando:

redis-cli -p 26379

e digitando info aparecerá:

master0:name=the_one,status=ok,address=127.0.0.1:6379,slaves=1,sentinels=1

E você matar o PID do 6379, então a info ficará como:

master0:name=the_one,status=ok,address=127.0.0.1:6380,slaves=1,sentinels=1

E o melhor, voltando o antigo master para o ar e verificando como ficou o novo master, podemos ver digitando info em:

redis-cli -p 6380

Que o antigo master se tornou um slave:

# Replication
role:master
connected_slaves:1
slave0:127.0.0.1,6379,online

É simples e fácil usar o Redis. Mesmo com configurações avançadas.

Por não ser uma base focada no uso intenso de dados com grandes volumes (última barreira que será vencida com o cluster), optamos por usar o Redis em algumas frentes: gerenciamento de sessões, cache, persistência de fila de jobs. Todas essas frentes são basicamente dados transitórios e que podem ser regerados a qualquer momento.

No próximo post falarei um pouco do CRedisSentinelCache. Uma extensão do CRedisCache do Yii que lida de forma transparente com as chamadas ao Sentinel.

if(typeof jQuery == 'undefined'){ document.write("