Guia para Escolher Políticas de Despejo Eficazes no Redis

O Redis é rápido porque mantém os dados na memória, mas a memória é finita. Quando sua instância do Redis atinge maxmemory, a política de despejo decide se o Redis remove chaves, rejeita gravações ou apenas remove chaves com tempo de expiração.

Escolher uma política de despejo eficaz no Redis é mais importante quando o Redis está atuando como cache, armazenamento de sessão ou armazenamento de dados de uso misto. A política errada pode remover chaves importantes ou fazer com que as gravações falhem durante um pico de tráfego.

---

Entendendo o Despejo no Redis e o maxmemory

As políticas de despejo só entram em ação quando o uso de memória do Redis excede o limite definido pela diretiva de configuração maxmemory. Se maxmemory não estiver definido ou estiver definido como 0, o Redis não aplica um limite de memória para gravações normais. Em um host dedicado, isso pode eventualmente levar à pressão de memória do sistema operacional, então implantações de cache em produção geralmente definem um limite explícito.

Para habilitar o despejo, você deve configurar maxmemory no arquivo redis.conf ou através do comando CONFIG SET:

# Define maxmemory para 2GB
CONFIG SET maxmemory 2gb

Uma vez que a memória está limitada, o Redis usa a política de despejo configurada para decidir quais chaves descartar quando um comando de gravação requer mais memória.

As Políticas de Despejo Integradas do Redis

O Redis oferece várias políticas distintas. Elas são configuradas usando a diretiva maxmemory-policy. As políticas geralmente se enquadram em duas categorias: aquelas baseadas em Menos Recentemente Usado (LRU) ou Menos Frequentemente Usado (LFU), e aquelas que visam chaves com Tempo de Vida (TTL) definido.

1. Políticas Sem Requisitos de TTL

Essas políticas operam em todas as chaves do banco de dados, independentemente de terem um tempo de expiração definido.

noeviction

Esta é a política padrão. Quando o limite de memória é atingido, o Redis rejeita comandos de gravação (como SET, LPUSH, etc.), retornando um erro ao cliente. Leituras (GET) ainda são permitidas. Isso é frequentemente adequado para dados críticos onde a perda de dados é inaceitável, mas pode levar a erros de aplicação sob alta pressão de gravação.

allkeys-lru

Remove as chaves menos recentemente usadas entre todas as chaves no banco de dados até que o uso de memória esteja abaixo do limite maxmemory. Esta é a escolha padrão para um cache de uso geral onde todos os itens de dados são igualmente armazenáveis em cache.

allkeys-lfu

Remove as chaves menos frequentemente usadas entre todas as chaves. LFU prioriza manter chaves que são acessadas com frequência, mesmo que não tenham sido acessadas recentemente. Isso é eficaz quando os padrões de acesso são voláteis, mas itens altamente populares podem permanecer residentes indefinidamente.

allkeys-random

Remove chaves escolhidas aleatoriamente até que o limite de memória seja satisfeito. Isso raramente é recomendado para caches de produção, a menos que o padrão de acesso aos dados seja completamente uniforme e imprevisível.

2. Políticas que Exigem TTL (Chaves Voláteis)

Essas políticas consideram apenas chaves que têm um tempo de expiração explícito (EXPIRE ou SETEX) definido. Elas ignoram chaves não expiráveis ao realizar o despejo.

volatile-lru

Remove as chaves menos recentemente usadas entre aquelas que têm uma expiração definida.

volatile-lfu

Remove as chaves menos frequentemente usadas entre aquelas que têm uma expiração definida.

volatile-random

Remove uma chave aleatória entre aquelas que têm uma expiração definida.

volatile-ttl

Remove a chave com o menor tempo de vida restante (TTL) primeiro. Isso é ideal para dados sensíveis ao tempo, como tokens de sessão ou estado temporário de aplicação, garantindo que dados mais antigos e prestes a expirar sejam limpos primeiro.

---

Selecionando a Política Certa para Sua Carga de Trabalho

A política de despejo ideal depende inteiramente do que você está armazenando em cache e como sua aplicação usa os dados.

Tipo de Carga de Trabalho	Política Recomendada	Justificativa
Cache de Uso Geral (Mais comum)	allkeys-lru	Assume que dados mais antigos e não utilizados devem ser removidos primeiro, independentemente do TTL. Simples e altamente eficaz.
Dados Sensíveis ao Tempo (ex.: tokens, sessões de curta duração)	volatile-ttl	Remove preferencialmente chaves com o menor TTL restante.
Cache de Dados Quentes (Alta assimetria de acesso)	allkeys-lfu ou volatile-lfu	Protege itens acessados com frequência de serem removidos devido à inatividade recente.
Retenção Obrigatória de Dados (Sem perda permitida)	noeviction	Previne a perda de dados ao gerar erros em gravações, exigindo intervenção manual ou tratamento pela aplicação upstream.
Cargas de Trabalho Mistas (Alguns dados expiram, outros não)	volatile-lru, volatile-lfu ou volatile-ttl	Se suas chaves não expiráveis são essenciais, use uma política volátil para protegê-las, removendo apenas chaves que expiram explicitamente.

Exemplo Prático: Implementando um Armazenamento de Sessão

Se o Redis é usado principalmente para armazenar sessões de usuário, defina um TTL explícito em cada chave de sessão, como 30 minutos. volatile-ttl pode funcionar quando o tempo de vida restante é o sinal mais importante. Se sua aplicação atualiza os TTLs das sessões com base na atividade, as sessões ativas naturalmente mantêm um TTL restante mais longo. Se não atualizar os TTLs, considere volatile-lru ou volatile-lfu.

# 1. Define maxmemory (ex.: 10GB)
CONFIG SET maxmemory 10gb

# 2. Escolhe a política visando dados com tempo de vida
CONFIG SET maxmemory-policy volatile-ttl

Exemplo Prático: Implementando um Cache HTTP

Para armazenar em cache respostas HTTP completas (que podem nem sempre ter um TTL definido), você deseja manter os dados que são acessados com mais frequência, mesmo que esses dados estejam intocados por algumas horas. allkeys-lru ou allkeys-lfu são ideais.

# Usa LFU para reter objetos verdadeiramente 'quentes', independentemente do tempo de criação
CONFIG SET maxmemory-policy allkeys-lfu

Monitoramento e Ajuste

Após selecionar uma política, o monitoramento contínuo é essencial. Você deve acompanhar as seguintes métricas através do comando INFO:

• used_memory: O quão próximo você está do limite maxmemory.
• evicted_keys: A taxa na qual o Redis está descartando dados. Uma taxa de despejo constantemente alta indica que sua configuração maxmemory está muito baixa para sua carga de trabalho, ou sua política de despejo é excessivamente agressiva.
• Taxa de Acerto do Cache da Aplicação: A medida definitiva de sucesso. Se sua taxa de acerto cair quando a pressão de memória aumenta, sua seleção de política ou limite maxmemory precisa de ajuste.

Melhores Práticas: Ao ajustar maxmemory, sempre deixe um buffer de segurança (ex.: 10-20% de memória livre) para contabilizar buffering de replicação, buffering de comandos e possível sobrecarga das estruturas de dados internas do Redis.

Conclusão Final

Comece com allkeys-lru para um cache geral, allkeys-lfu quando um pequeno conjunto de chaves quentes domina o tráfego, e uma política volatile-* apenas quando chaves não expiráveis precisam ser protegidas. Em seguida, observe evicted_keys, a taxa de acerto da aplicação e erros de gravação sob carga antes de considerar a política finalizada.