Redis e Valkey — Guia Prático: Padrões de Cache, Políticas de Evicção e Cache Stampedes

A Mudança de Licença do Redis e a Ascensão do Valkey

Os motores de armazenamento em memória são o coração de qualquer aplicação web que exija tempos de resposta inferiores a um milissegundo. Durante mais de quinze anos, o Redis foi a referência absoluta para gerir sessões, caches de páginas e filas de processamento rápido. No entanto, as recentes alterações de licença comercial do Redis levaram a comunidade de software livre—liderada pela Linux Foundation com o apoio de gigantes como AWS e Google Cloud—a criar o fork Valkey.

O Valkey mantém a licença livre original BSD de três cláusulas, garante compatibilidade total com os comandos do Redis 7.2 e melhora o processamento multi-thread de sockets de rede no Debian. Independentemente de usares Redis ou Valkey, tratares a cache em memória como um balde mágico onde atiras chaves sem estratégia é a receita ideal para quebras de consistência, fragmentação de RAM e quedas graves de bases de dados em produção.

A TRANSIÇÃO DO REDIS PARA O NOVO VALKEY

• REDIS ORIGINAL DE CÓDIGO ABERTO (Licença BSD Livre)
• Redis Comercial (Licenças Proprietárias SSPLv1/RSALv2)
• VALKEY (Governação Comunitária sob a Linux Foundation)
• 100% Compatível com Bibliotecas e Comandos Anteriores
• Melhorias Nativas de Desempenho Multi-Thread
• Suporte Direto nos Repositórios Principais de Linux

Na Webxtek, desenhamos arquiteturas de cache que funcionam como verdadeiros amortecedores de choque. Quando desenvolvemos websites de alta performance e arquiteturas escaláveis para web apps, garantimos que a tua infraestrutura aguenta picos violentos de visitantes com tempos de resposta imediatos.

Padrões de Cache: Cache-Aside vs. Write-Through na Prática

A forma como geres a leitura e escrita de dados determina a frescura da informação e o esforço exigido à tua infraestrutura.

1. O Padrão Cache-Aside (Carregamento Preguiçoso)

No padrão Cache-Aside, a cache não fala diretamente com a base de dados. É a tua própria aplicação que coordena o fluxo:

FLUXO DO PADRÃO CACHE-ASIDE

1. O Cliente Pede o Perfil de Utilizador (ID: 481)

• 2. A Aplicação Pergunta ao Valkey → Chave Existe? → Devolve Perfil (0.4ms)
• (Cache Miss - Não Encontrou!)
• 3. A Aplicação Consulta a Base de Dados PostgreSQL (12ms)

4. A Aplicação Grava os Dados no Valkey com TTL (ex: EX 3600 segundos)

• 5. Devolve os Dados ao Utilizador

Vantagens: Se o servidor de cache falhar, a aplicação continua a funcionar lendo a base de dados; a memória só guarda o que é realmente consultado.
Desvantagens: O primeiro pedido tem uma penalização de tempo; se a base de dados mudar diretamente, a cache pode servir dados desatualizados.

2. O Padrão Write-Through

No Write-Through, a aplicação escreve diretamente no Valkey, que tem a responsabilidade de atualizar síncronamente o PostgreSQL antes de confirmar a operação.

ESCRITA SÍNCRONA WRITE-THROUGH

• A Tua Aplicação Envia uma Alteração
• Motor de Memória: Valkey: (Escrita Atómica) → [ Base de Dados PostgreSQL ]
• Ambos Confirmam com Sucesso
• Devolve Sucesso HTTP 200 ao Cliente

O Pesadelo da Manada: Como Travar Cache Stampedes

Um cache stampede (ou efeito manada) acontece quando uma chave com centenas de pedidos por segundo chega ao fim do seu tempo de vida (TTL). Imagina que a página principal da tua loja expira às 14:00:00. Naquele exato microssegundo, 500 utilizadores em simultâneo sofrem um cache miss. Todos tentam correr a mesma consulta pesada à base de dados, o processador vai aos 100% e o servidor cai.

O COLAPSO DE UM CACHE STAMPEDE (EFEITO MANADA)

• A Chave produtos:destaques Expira às 14:00:00!
• Pedido 1 (Miss)
• Pedido 2 (Miss) → [ 500 Consultas SQL em Simultâneo! ]
• Pedido 3 (Miss) → [ Ligações da Base de Dados Esgotadas ]
• Pedido 500 (Miss) → [ Erros HTTP 504 no Servidor Web ]

A Solução: Trincos de Mutex Distribuídos com SETNX

Para impedires esta tragédia, apenas o primeiro processo que deteta a ausência da chave deve ter autorização para consultar a base de dados. Todos os outros processos esperam ou recebem dados ligeiramente antigos:

// Exemplo em Node.js com trinco distribuído atómico
async function obterCatalogoComTrinco(valkey, postgres) {
  const chaveCache = "produtos:destaques";
  let dados = await valkey.get(chaveCache);

  if (!dados) {
    const chaveTrinco = `trinco:${chaveCache}`;
    // Tenta adquirir o trinco atómico por 5 segundos
    const adquiriu = await valkey.set(chaveTrinco, "ocupado", "NX", "EX", 5);

    if (adquiriu) {
      try {
        // Apenas este processo vai à base de dados
        dados = await postgres.query("SELECT * FROM produtos WHERE destaque = true");
        await valkey.set(chaveCache, JSON.stringify(dados), "EX", 300);
      } finally {
        await valkey.del(chaveTrinco);
      }
    } else {
      // Os outros processos aguardam 50ms e tentam ler novamente
      await new Promise((resolve) => setTimeout(resolve, 50));
      return obterCatalogoComTrinco(valkey, postgres);
    }
  }
  return JSON.parse(dados);
}

Políticas de Evicção: volatile-lru vs. allkeys-lru

Quando o Valkey atinge o limite máximo de memória RAM permitido (maxmemory), ele é obrigado a apagar chaves antigas para conseguir gravar as novas. Se escolheres a política errada, podes perder dados críticos de sessão.

Configura o teu ficheiro /etc/valkey/valkey.conf:

# Limite máximo de memória atribuído
maxmemory 4gb

# Política de expulsão de chaves
maxmemory-policy volatile-lru

# Precisão do algoritmo de amostragem
maxmemory-samples 7

POLÍTICAS DE EVICÇÃO NO VALKEY

• ESTRATÉGIA: volatile-lru
• Só apaga chaves que tenham um tempo de expiração (TTL) configurado.
• Perfeito para instâncias que partilham caches temporárias com sessões permanentes.
• Se a memória encher e não houver chaves com TTL, devolve erro em vez de apagar dados.
• ESTRATÉGIA: allkeys-lru
• Apaga qualquer chave antiga para libertar espaço para novos dados.
• Ideal para instâncias dedicadas exclusivamente a cache de páginas.
• Perigoso se tiveres filas de trabalho ou tokens permanentes na mesma máquina.

Como Configurar a Persistência em Produção

Se a tua instância de Valkey é usada exclusivamente para cache de páginas web, deves desligar completamente a persistência em disco (save "" e appendonly no). Isto elimina operações desnecessárias de escrita e garante tempos de resposta recorde.

Se usares o Valkey para guardar sessões de utilizadores, ativa o ficheiro de registo contínuo (AOF):

# Ativa o modo de escrita contínua com sincronização por segundo
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Podes encontrar modelos práticos de monitorização para Prometheus no GitHub para acompanhar o consumo de memória em tempo real.

Combinando o Valkey afinado com os nossos serviços de alojamento gerido, garantes que as tuas plataformas web respondem com máxima velocidade, escalabilidade imediata e proteção absoluta das tuas bases de dados.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como saas empresarial b2b e provedores de cloud computing e iaas. Quando alinhas a tua estrutura através de websites de alta performance e alojamento gerido para websites e aplicações, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.