Redis: o que é, como funciona e quando usar

O que é Redis?

Redis é um servidor de estruturas de dados em memória, acessado por aplicações por meio de uma conexão de rede e comandos.

Em vez de oferecer apenas valores simples, ele entende tipos com operações próprias, como adicionar um item a uma lista, incrementar um contador ou consultar os primeiros colocados de um ranking.

O nome é frequentemente associado a cache porque esse é um dos usos mais conhecidos.

Entretanto, o Redis também pode guardar estado de curta duração, coordenar processos, publicar mensagens, manter streams de eventos, realizar buscas e atuar como banco de dados quando suas garantias e estruturas combinam com o problema.

A documentação oficial dos tipos de dados do Redis o descreve como um servidor de estruturas capaz de atender problemas que vão de cache e filas ao processamento de eventos.

Como o Redis funciona

A aplicação utiliza uma biblioteca cliente compatível com sua linguagem e abre uma conexão com o servidor Redis.

Cada dado é identificado por uma chave. O cliente envia comandos para criar, ler, alterar, expirar ou remover a estrutura associada a essa chave.

Um exemplo simples é armazenar o resumo de um produto sob a chave produto:42. A aplicação pode definir um tempo de validade e consultar essa chave antes de acessar o banco principal.

Se o dado existir, utiliza o valor; se não existir, busca a fonte original e repovoa o cache.

1. A aplicação solicita um dado ao Redis.
2. O servidor localiza a chave e executa a operação sobre sua estrutura.
3. Se a chave estiver disponível, a resposta retorna sem consultar a fonte mais lenta.
4. Quando a chave não existe ou expirou, a aplicação decide como reconstruí-la.

A simplicidade aparente esconde decisões de arquitetura. É preciso definir nomes de chaves, validade, tamanho, política de remoção, comportamento em falhas e se o dado pode ser reconstruído.

Por que o Redis é rápido?

O Redis mantém o conjunto de dados ativo principalmente em memória RAM, evitando o caminho mais lento de leituras aleatórias em armazenamento persistente para cada comando.

Suas estruturas e operações foram desenhadas para acesso eficiente.

Muitas operações são executadas de forma atômica no servidor. Incrementar um contador, por exemplo, não exige que a aplicação leia o valor, calcule o próximo e grave novamente em três etapas independentes.

Velocidade não significa ausência de limites. Rede, serialização, tamanho dos valores, comandos pesados, persistência e replicação influenciam a latência. Um Redis remoto e mal modelado pode apresentar desempenho inferior ao esperado.

Principais estruturas de dados

Estrutura	O que representa	Exemplo de uso
String	Sequência de bytes, texto ou número	Cache, token, contador
Hash	Campos e valores associados	Perfil ou objeto compacto
List	Sequência pela ordem de inserção	Fila simples e histórico curto
Set	Coleção sem elementos repetidos	Permissões e relações únicas
Sorted set	Itens únicos ordenados por pontuação	Ranking e prioridade
Stream	Log de entradas ordenadas	Eventos e consumo por grupos

Escolher a estrutura correta é mais importante do que guardar tudo como JSON ou texto.

Um sorted set pode manter um ranking sem exigir que a aplicação carregue e ordene a coleção inteira.

Um set pode verificar participação sem percorrer uma lista.

O Redis moderno também oferece tipos voltados a geolocalização, dados probabilísticos, séries temporais, JSON e vetores.

Esses recursos ampliam os casos de uso, mas devem ser adotados quando simplificam uma necessidade concreta.

Como usar Redis como cache

No padrão cache-aside, a aplicação controla o fluxo. Primeiro consulta o Redis. Se a chave existir, ocorre um cache hit.

Se não existir, acontece um cache miss: a aplicação busca o dado no banco, devolve a resposta e grava uma cópia com validade limitada.

O ganho vem da reutilização de dados caros e frequentes. Catálogos, configurações, resultados agregados e respostas estáveis são candidatos comuns.

O cache reduz leituras no banco, mas introduz a possibilidade de servir uma cópia desatualizada.

A invalidação precisa acompanhar a tolerância do negócio. Alguns dados podem ficar defasados por minutos; saldo, estoque ou permissão talvez exijam atualização imediata.

Em vez de procurar uma regra única, defina consistência e validade por tipo de informação.

A explicação de cache da AWS destaca que essa camada guarda um subconjunto normalmente transitório para responder mais rápido do que a fonte original.

Essa descrição ajuda a lembrar que cache não é automaticamente a cópia completa e durável do sistema.

TTL e políticas de remoção

TTL significa time to live, o tempo durante o qual uma chave permanece válida. Depois do vencimento, ela deixa de estar disponível e pode ser removida. O TTL limita a duração de sessões, códigos temporários e cópias de cache.

Além da expiração programada, o Redis pode precisar liberar memória quando atinge o limite configurado.

A política de eviction define se o servidor rejeita novas gravações ou escolhe chaves para remover com base em critérios como recência, frequência, aleatoriedade ou TTL.

Uma política inadequada pode apagar dados que a aplicação considerava essenciais. Se o Redis contém estado que não pode ser reconstruído, não trate a remoção como detalhe de performance.

Persistência: RDB e AOF

Embora trabalhe em memória, o Redis pode gravar informações em disco para reconstruir o conjunto de dados após reinicializações. As duas abordagens principais são RDB e AOF.

• RDB: cria snapshots do conjunto de dados em momentos determinados. É compacto e útil para backups, mas alterações posteriores ao último snapshot podem ser perdidas.
• AOF: registra operações de escrita em um arquivo que pode ser reproduzido na inicialização. Permite reduzir a janela de perda, com custos de gravação e manutenção do log.
• RDB e AOF: podem ser combinados quando os trade-offs justificam.
• Sem persistência: pode fazer sentido para um cache totalmente reconstruível.

A documentação oficial de persistência detalha esses modos. Ativar persistência não elimina a necessidade de backup, teste de restauração e definição clara da perda de dados aceitável.

Replicação, Sentinel e Cluster

Na replicação, uma instância principal envia alterações para réplicas. Elas podem atender leituras, oferecer cópias adicionais e participar da recuperação quando a principal falha.

A replicação padrão é assíncrona, portanto existe uma janela em que uma escrita confirmada pela principal ainda não chegou a todas as réplicas.

Redis Sentinel adiciona monitoramento, descoberta e failover para uma implantação que utiliza principal e réplicas.

Redis Cluster distribui o espaço de chaves entre nós, permitindo particionar dados e aumentar capacidade. São problemas diferentes: replicar cria cópias; particionar divide o conjunto.

A documentação oficial de replicação do Redis explica sincronização parcial, sincronização completa e os limites da confirmação assíncrona.

Réplica não substitui backup: uma remoção incorreta pode ser replicada para todas as cópias.

Principais casos de uso

Cache de aplicação

Guarda resultados frequentes para reduzir latência e aliviar o banco. É o cenário clássico, mas exige TTL, invalidação e proteção contra picos de cache miss.

Sessões compartilhadas

Várias instâncias da aplicação podem consultar o mesmo estado de sessão. Isso reduz a dependência de sticky sessions e combina com balanceamento de carga.

Contadores e rate limiting

Operações atômicas e expiração permitem contar acessos por janela de tempo, controlar tentativas e implementar limites.

Regras mais avançadas precisam considerar concorrência e precisão.

Filas, Pub/Sub e streams

Lists, Pub/Sub e Streams atendem modelos diferentes de comunicação. Para escolher corretamente entre retenção, confirmação e grupos de consumidores, vale começar pelo guia sobre fila de mensagens.

Rankings e prioridades

Sorted sets associam pontuação a membros únicos e permitem obter intervalos ordenados. Isso é útil para placares, prioridades, agendamentos e listas de destaque.

Redis substitui um banco de dados?

Redis pode ser o banco principal de um caso de uso, mas não é uma substituição automática para bancos relacionais ou documentais.

A decisão depende de consultas, volume, durabilidade, consistência, custo de memória e modelo de dados.

Um banco como PostgreSQL oferece relacionamentos, restrições, consultas complexas e transações adequadas a muitos dados de negócio.

Redis oferece acesso rápido a estruturas específicas e expiração nativa. Em várias arquiteturas, os dois trabalham juntos.

Se você ainda está construindo a base sobre bancos tradicionais, o guia de PostgreSQL para iniciantes ajuda a comparar as responsabilidades sem reduzir a escolha à velocidade.

Benefícios e limitações

Benefícios	Limitações
Baixa latência para operações em memória	RAM costuma ser mais cara que disco
Estruturas e comandos atômicos úteis	Modelagem exige conhecer comandos e complexidade
TTL e expiração nativos	Eviction pode remover chaves sob pressão
Replicação e opções de alta disponibilidade	Replicação assíncrona admite janelas de perda
Atende cache, sessão, contadores e streams	Não oferece as mesmas consultas de um banco relacional

O principal erro é avaliar apenas a velocidade. Uma solução rápida que perde estado essencial, serve dados antigos ou custa mais do que o benefício não é uma boa solução.

Quando usar Redis

• leituras repetidas estão pressionando a fonte principal;
• dados temporários precisam de expiração automática;
• várias instâncias precisam compartilhar sessões ou contadores;
• operações atômicas simples evitam concorrência na aplicação;
• rankings, conjuntos e filas combinam com estruturas nativas;
• baixa latência é relevante e o conjunto ativo cabe no orçamento de memória.

Redis também pode aliviar sistemas que já usam índices no banco de dados, mas não deve mascarar consultas mal planejadas. Primeiro meça a origem da lentidão; depois escolha a camada apropriada.

Quando evitar

Evite adicionar Redis apenas porque a aplicação “pode ficar mais rápida”. Se o volume é pequeno e o banco responde bem, uma nova dependência aumenta operação, segurança e pontos de falha sem retorno claro.

Também seja cuidadoso quando o conjunto de dados é grande demais para memória, exige consultas relacionais complexas ou não tolera a janela de perda definida pela persistência e replicação. Nesses casos, outro banco ou uma arquitetura híbrida pode ser mais adequado.

Distribuir mais dados entre nós não é gratuito. Assim como no sharding de banco de dados, particionamento exige entender chaves, movimentação, hotspots e comportamento durante falhas.

Segurança e exposição de dados

Redis não deve ficar exposto diretamente à internet. Restrinja o acesso por rede, utilize autenticação e listas de controle, proteja conexões com TLS quando apropriado e conceda somente os comandos necessários a cada aplicação.

Não armazene senhas, tokens ou dados pessoais sem avaliar necessidade, criptografia, retenção e acesso. Cópias temporárias também são dados sensíveis. TTL reduz o tempo de permanência, mas não substitui uma política de segurança.

Credenciais devem permanecer fora do código e passar por rotação. O artigo sobre gerenciamento de segredos explica como proteger chaves e tokens usados por aplicações e pipelines.

Boas práticas de implementação

• Defina um padrão legível de nomes e namespaces para chaves.
• Configure limite de memória e política de eviction conscientemente.
• Use TTL em dados temporários e evite chaves esquecidas.
• Não armazene objetos enormes quando campos menores resolvem.
• Evite comandos que percorrem todo o espaço de chaves em produção.
• Monitore memória, latência, conexões, cache hit, evictions e replicação.
• Planeje o comportamento quando Redis ficar lento ou indisponível.
• Teste restauração, failover e reconstrução do cache.

Proteja também a fonte principal contra uma avalanche de cache miss. Expirações aleatórias, renovação antecipada, bloqueio por chave e limites de concorrência podem impedir que milhares de solicitações reconstruam o mesmo dado simultaneamente.

Erros comuns

• Usar Redis sem medir: a complexidade entra antes da necessidade.
• Não definir TTL: chaves temporárias ocupam memória indefinidamente.
• Tratar cache como fonte única: eviction ou falha causa perda inesperada.
• Ignorar invalidação: usuários recebem informações desatualizadas.
• Guardar valores grandes: rede, memória e operações ficam mais caras.
• Confiar apenas na réplica: erro lógico e remoção podem se propagar.
• Expor a porta publicamente: a camada rápida se torna uma superfície crítica de ataque.

Perguntas frequentes

Redis é cache ou banco de dados?

Pode exercer os dois papéis. Redis é um servidor de estruturas de dados; cache é um uso frequente, enquanto persistência e outros recursos permitem utilizá-lo como banco em cenários compatíveis.

Redis guarda dados no disco?

Sim, quando a persistência está configurada. RDB cria snapshots e AOF registra operações de escrita. Também é possível desativar persistência para caches reconstruíveis.

Redis pode perder dados?

Pode. A janela depende da persistência, replicação e do tipo de falha. Eviction e expiração também removem chaves conforme a configuração.

Redis ou Memcached: qual escolher?

Memcached atende cache simples de chave e valor. Redis oferece estruturas mais variadas, persistência, replicação e recursos adicionais. Escolha pelo comportamento necessário e pelo custo operacional.

Redis serve para fila de mensagens?

Sim, com listas ou Streams, mas as garantias variam. Pub/Sub não retém mensagens para consumidores desconectados. Compare retenção, confirmação e recuperação antes de escolher.

Toda chave do Redis precisa de TTL?

Não. Chaves persistentes podem ser intencionais. Entretanto, dados temporários, sessões e cache normalmente precisam de expiração para evitar acúmulo e informações antigas.

É seguro usar Redis em produção?

Sim, desde que rede, autenticação, TLS, memória, persistência, backups, monitoramento e recuperação sejam configurados conforme o risco do sistema.

Conclusão

Redis combina acesso em memória com estruturas de dados e comandos que resolvem cache, sessões, contadores, rankings, filas e outros problemas de baixa latência.

Seu valor não está apenas em “ser rápido”, mas em oferecer operações adequadas ao problema. Em troca, a equipe precisa controlar memória, expiração, consistência, persistência, replicação e segurança.

Comece por um caso mensurável, como uma consulta frequente ou sessão compartilhada. Defina o que acontece em um cache miss e em uma falha completa.

Assim, Redis melhora o sistema sem se transformar em uma dependência que ninguém sabe reconstruir.