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
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
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.