Redis como cache ou como banco: diferenças e persistência

O Redis guarda os dados na RAM, e é isso que o deixa tão rápido. A mesma característica gera a dúvida mais comum sobre ele: se a memória some quando o processo para, dá para confiar nele para guardar dados de verdade?

Depende do papel que ele cumpre na sua aplicação. Como cache, perder os dados é aceitável. Como banco, não é, e aí você precisa configurar a persistência em disco. Para a visão geral da ferramenta, veja o que é Redis.

Qual é a diferença entre usar o Redis como cache e como banco?#

A pergunta que separa os dois usos é: se esse dado sumir, eu consigo recriá-lo?

• Cache: o dado é uma cópia de algo que já existe em outro banco ou pode ser recalculado. Se sumir, a aplicação busca de novo na origem. O Redis só acelera.
• Banco: o dado só existe no Redis (sessões, filas, contadores, rankings). Se sumir, ele se perde de vez.

Como usar o Redis como cache?#

O padrão mais comum é o cache-aside: a aplicação consulta o cache primeiro e, só quando não encontra o dado (miss), vai ao banco e guarda o resultado com prazo de validade.

// npm install ioredis pg
import { Redis } from "ioredis";
import pg from "pg";

const redis = new Redis(process.env.REDIS_URL);
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

export async function getUser(id) {
  const key = `user:${id}`;

  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached); // hit

  const { rows } = await pool.query("SELECT id, name FROM users WHERE id = $1", [id]);
  if (rows.length === 0) return null;

  await redis.set(key, JSON.stringify(rows[0]), "EX", 60); // expira em 60 s
  return rows[0];
}

Dois pontos pesam mais que o código:

1. Todo cache precisa de TTL. O EX 60 faz a chave expirar em 60 segundos. Sem prazo, o cache vira uma cópia velha que ninguém invalida. Detalhes do comando em EXPIRE.
2. Quando o dado muda no banco, invalide a chave (redis.del(key)) ou aceite que o cache fique defasado até o TTL acabar.

Como o cache é descartável, a persistência pode ficar desligada. A própria documentação do Redis cita o modo sem persistência como uma configuração usada às vezes em caches.

O que acontece quando o cache enche a memória?#

O limite de memória só existe se você configurar um. A diretiva maxmemory define o teto, e maxmemory-policy define o que fazer ao atingi-lo:

redis-cli CONFIG SET maxmemory 256mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Sem maxmemory, o limite em sistemas de 64 bits é zero, ou seja, não há teto: o Redis continua crescendo até esgotar a memória disponível na máquina ou no contêiner. As políticas mais usadas, segundo a documentação oficial:

• noeviction: não remove nada e retorna erro nos comandos que adicionam dados. Comandos de leitura continuam funcionando.
• allkeys-lru: remove as chaves usadas há mais tempo. A documentação a indica como boa opção padrão quando poucas chaves recebem a maior parte dos acessos.
• allkeys-lfu: remove as chaves menos acessadas.
• volatile-lru, volatile-ttl e variantes: só removem chaves que têm TTL. Sem nenhuma chave com expiração, elas se comportam como noeviction.

Para cache puro, allkeys-lru é o ponto de partida. Para o Redis como banco, use noeviction: um erro de memória cheia é melhor do que apagar dados em silêncio.

Como o Redis grava dados no disco?#

Existem duas formas de persistência, que você pode usar separadas ou juntas, segundo a documentação de persistência.

RDB: fotos periódicas#

O RDB salva uma foto do conjunto de dados num arquivo (dump.rdb) em intervalos definidos. Esta regra grava a cada 60 segundos se pelo menos 1000 chaves mudaram:

save 60 1000

O arquivo é compacto, bom para cópias de segurança, e acelera o reinício do Redis com bases grandes. O custo: se o processo cair sem um desligamento limpo, você perde o que foi escrito desde a última foto, em geral alguns minutos.

AOF: registro de cada escrita#

O AOF (append-only file) anexa cada comando de escrita a um log, que é reproduzido na inicialização para reconstruir os dados. Para ativar:

appendonly yes

A durabilidade depende da política appendfsync:

O AOF costuma gerar arquivos maiores que o RDB e, dependendo da política de fsync, pode ser mais lento. O Redis reescreve o log em segundo plano para que ele não cresça sem parar.

RDB, AOF ou os dois?#

A documentação do Redis recomenda:

• Quer segurança de dados comparável à de um banco como o PostgreSQL: use os dois.
• Pode aceitar perder alguns minutos em caso de desastre: RDB sozinho basta.
• AOF sozinho é comum, mas a documentação desencoraja, porque um RDB de tempos em tempos ajuda em cópias, em reinícios mais rápidos e em caso de bugs no motor do AOF.

Com os dois ativos, o Redis usa o AOF para reconstruir os dados no reinício, porque ele é o mais completo.

Quando usar cada modo?#

Use o Redis como cache quando:

• a origem dos dados é outro banco e a consulta nele é lenta ou cara;
• o dado pode ficar alguns segundos defasado;
• a perda total do cache só causa lentidão temporária, não erro.

Use o Redis como banco quando:

• o dado é naturalmente em memória e de acesso rápido: sessões, filas, contadores, limitação de taxa, rankings;
• você aceita a janela de perda da persistência escolhida;
• todo o conjunto cabe na RAM com folga.

Prefira outro banco quando o dado é relacional, precisa de consultas complexas ou não pode perder nem um segundo de escritas. Nesse caso, veja qual banco de dados escolher.

Dá para misturar os dois papéis numa instância, mas a documentação sugere separar em duas instâncias quando possível: um cache com remoção de chaves e um Redis persistente sem remoção.

Persistência é o mesmo que backup?#

Não. A persistência faz o Redis sobreviver a um restart no mesmo disco. Se o disco ou a máquina se perdem, os arquivos vão junto, então você ainda precisa de cópias fora da máquina. O arquivo RDB é seguro de copiar com o servidor em execução, porque nunca é modificado depois de pronto. O guia de como fazer backup de um banco de dados cobre a rotina completa.

Como fazer isso na Square Cloud#

A Square Cloud oferece hospedagem de Redis a partir do plano Standard, com persistência. Você cria o banco no painel, e ele fica pronto em segundos no mesmo datacenter das aplicações, com latência média de cerca de 1 ms. A conexão usa TLS obrigatório (rediss://, com o certificado baixado no painel). O plano Hobby não inclui hospedagem de banco.

Como o Redis guarda tudo na RAM, o tamanho do conjunto de dados define quanta memória você aloca para ele, a partir de 512 MB. Para cache, dê um TTL a cada chave, como no exemplo acima, para que o conjunto de dados não cresça sem teto. Há um único database lógico, então separe cache e dados permanentes por prefixo de chave. Use também um cliente que reconecte sozinho, porque clientes ociosos são desconectados após 5 minutos.

Você tira snapshots manuais quando quiser, e todo plano com bancos inclui também um snapshot automático diário. Um snapshot pode ser restaurado no mesmo banco, em outro do mesmo motor ou num banco novo, ou baixado como .zip. Veja hospedagem de Redis na Square Cloud e snapshots.