Redis é uma das peças mais fáceis de colocar em produção e uma das mais fáceis de colocar em produção errado. Ele sobe em um comando, responde em microssegundos e resolve cache, sessão, fila e contador com uma elegância que dá vontade de usar para tudo. Os problemas aparecem depois, e quase nunca aparecem como "o Redis está com defeito" — aparecem como aplicação lenta de forma inexplicável, usuário deslogado sem motivo ou tarefa que simplesmente não foi processada.

O ponto de partida: Redis não é banco de dados por padrão

Redis guarda os dados em memória. Ele oferece dois mecanismos de persistência, e é essencial entender que nenhum dos dois é equivalente a um banco transacional.

O primeiro tira uma fotografia periódica do conjunto de dados. É eficiente, e a janela de perda é o intervalo entre fotografias — se a última foi cinco minutos atrás, você perde cinco minutos.

O segundo registra cada operação de escrita em um arquivo. A janela de perda fica muito menor, ao custo de mais escrita em disco. Ainda assim, com a configuração usual de gravação a cada segundo, existe uma janela de perda de aproximadamente um segundo.

A conclusão prática: use Redis para o que tolera perda — cache, sessão, contador, fila com reprocessamento. Se o dado não pode ser perdido de jeito nenhum, ele precisa estar também em outro lugar. É espantosamente comum encontrar dado que só existe no Redis sem que ninguém tenha tomado essa decisão consciente: começou como cache e virou, na prática, a fonte da verdade.

Política de memória: o item de configuração mais negligenciado

Aqui está a armadilha que causa mais incidentes. Se você não configurar um limite de memória, o Redis cresce até acabar a memória do servidor — e o sistema operacional mata o processo. Se você configurar o limite mas deixar a política padrão de descarte, acontece algo pior e mais confuso: ao atingir o limite, o Redis passa a recusar escritas com erro, em vez de descartar chaves antigas.

O sintoma é desconcertante: a aplicação começa a falhar ao gravar no cache, com o servidor aparentemente saudável.

O que configurar, conforme o uso:

• Para cache puro: limite de memória definido e política que descarta as chaves menos usadas recentemente. É o comportamento que a maioria espera e quase ninguém configura.
• Para sessão de usuário: cuidado redobrado. Política de descarte agressiva significa usuário deslogado quando a memória aprieta. Dimensione com folga e prefira descartar apenas chaves com validade definida.
• Para fila: descarte é inaceitável — descartar significa perder tarefa. Separe a fila em outra instância, com limite dimensionado e alerta de crescimento.

Essa é a razão principal para não misturar usos na mesma instância: cache, sessão e fila querem políticas de memória incompatíveis entre si.

Um comando lento para tudo

Redis processa comandos em uma única linha de execução. Isso é ótimo para consistência e é a origem do modo de falha mais assustador: qualquer comando lento bloqueia todos os outros clientes.

Um comando que varre todas as chaves para encontrar um padrão, num banco com milhões de chaves, pode bloquear a instância por segundos. Durante esses segundos, cada requisição da sua aplicação que toca o Redis fica esperando. O resultado é uma indisponibilidade generalizada causada por um script de manutenção que alguém rodou "só para verificar uma coisa".

O que evitar em produção:

1. Varredura completa de chaves por padrão. Existe a alternativa incremental, que percorre em pedaços sem bloquear.
2. Operações que retornam coleções inteiras quando a coleção é grande. Peça em faixas.
3. Remoção de chave gigante de forma síncrona. Apagar uma estrutura com milhões de elementos leva tempo; existe a variante que libera a memória em segundo plano.
4. Scripts complexos, que executam de forma atômica — e portanto bloqueiam durante toda a execução.

A defesa estrutural é evitar a chave gigante: uma estrutura única com milhões de elementos é um risco permanente, porque qualquer operação sobre ela é lenta. Divida por faixa ou por período.

A pausa que a fotografia provoca

Um detalhe de comportamento que gera picos de latência difíceis de rastrear: para gravar a fotografia em disco, o Redis duplica o processo. A duplicação em si é rápida, mas em instância com muita memória ela causa uma pausa perceptível — e, mais importante, o consumo de memória pode subir bastante durante a gravação, porque as páginas alteradas passam a ser copiadas.

Duas consequências práticas. Instância com uso de memória perto do limite físico pode falhar ao gravar a fotografia, justamente por não ter memória para o processo duplicado. E vale reservar folga de memória no servidor além do limite configurado no Redis — contar com o limite como se fosse o consumo total é subdimensionar.

Replicação é assíncrona: aceite a perda

A réplica do Redis recebe as escritas de forma assíncrona. O primário confirma para o cliente e depois envia para a réplica.

Isso significa que, quando o primário morre e a réplica é promovida, as escritas que estavam em trânsito são perdidas. Não é defeito: é a escolha de projeto que dá ao Redis a latência que ele tem.

Para tornar a operação previsível, escolha o mecanismo com clareza:

• Sentinel monitora e promove réplica automaticamente, mantendo o modelo de um primário. É o caminho mais simples para alta disponibilidade.
• Cluster distribui os dados entre vários primários, escalando escrita e memória além de um servidor. Adiciona restrições: operações que tocam várias chaves precisam que elas estejam na mesma partição.

Em qualquer dos dois, a promoção automática exige quórum bem configurado — os mesmos cuidados de qualquer sistema distribuído valem aqui, e Sentinel mal dimensionado é uma fonte conhecida de promoção indevida.

Fila com Redis: o jeito ingênuo perde tarefa

Usar Redis como fila é comum e legítimo. O problema é o padrão mais intuitivo: o consumidor retira a tarefa da lista e processa. Se o processo morre depois de retirar e antes de concluir, a tarefa desapareceu. Não está na fila nem foi executada.

Os caminhos corretos:

• Retirar e colocar em uma lista de processamento ao mesmo tempo, de forma atômica. A tarefa fica visível como "em andamento" e pode ser recuperada se o consumidor morrer.
• Usar a estrutura de fluxo do Redis, com grupos de consumidores, que foi desenhada exatamente para isso: mantém registro do que foi entregue e não confirmado, permitindo reclamar tarefas de consumidor morto.

E, independentemente do mecanismo: garanta que o processamento seja idempotente. Em qualquer sistema de fila, a mesma tarefa pode ser entregue duas vezes. Se o efeito de processar duas vezes é uma cobrança duplicada, o problema está na aplicação, não na fila.

Cache: a avalanche e a validade uniforme

Dois problemas específicos de cache que aparecem em escala:

O primeiro é a avalanche. A chave popular expira, mil requisições simultâneas não encontram o valor e todas vão ao banco de dados ao mesmo tempo. O banco cai. A defesa é permitir que apenas uma requisição recalcule, com as outras aguardando ou recebendo o valor antigo por um instante.

O segundo é a validade uniforme. Se você preencheu o cache de uma vez com validade idêntica, tudo expira no mesmo segundo. Acrescente uma variação aleatória à validade para distribuir a renovação no tempo.

E a regra que evita crescimento infinito: toda chave de cache tem validade. Chave sem prazo em instância de cache é vazamento de memória com outro nome.

Exposição: o erro mais grave e mais comum

Redis foi projetado para rede confiável. Historicamente, instâncias abertas na internet sem autenticação foram uma das maiores fontes de comprometimento de servidor que existem — porque quem acessa um Redis sem restrição consegue, com alguma frequência, escrever arquivos no servidor.

O mínimo obrigatório: nunca exposto à internet, escutando apenas na interface interna, com autenticação ativada e senha forte, comandos administrativos perigosos renomeados ou desativados e, quando possível, tráfego cifrado. Isso não é endurecimento avançado — é a configuração básica que uma instância de produção precisa ter no primeiro dia.

Erros comuns

• Dado que só existe no Redis, sem decisão consciente.
• Nenhum limite de memória, até o processo ser morto pelo sistema.
• Limite configurado com política padrão, causando recusa de escrita.
• Cache, sessão e fila na mesma instância, com políticas incompatíveis.
• Varredura completa de chaves em produção, bloqueando tudo.
• Chave gigante, tornando qualquer operação lenta.
• Fila que retira sem registrar em processamento, perdendo tarefa.
• Processamento não idempotente, com efeito duplicado.
• Chaves de cache sem validade definida.
• Validade uniforme, gerando expiração em massa.
• Redis exposto sem autenticação.

Onde a Solvefy/Cloud entra

Em consultoria DevOps, Redis é uma das peças em que mais encontramos ganho rápido: quase sempre há política de memória errada, usos misturados na mesma instância ou fila que perde tarefa em silêncio. Revisamos a configuração, separamos os usos conforme o que cada um tolera, ajustamos persistência e alta disponibilidade ao risco real e corrigimos os padrões de fila e de cache na aplicação. Também implantamos o monitoramento que antecipa: memória, latência de comando e crescimento de chave.

Quer uma revisão do seu Redis antes do próximo incidente? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.