WordPress com Redis: cache de objetos sem inconsistências

Resposta rápida

O Redis object cache guarda resultados de consultas para que o WordPress não refaça o mesmo trabalho a cada requisição. A configuração só está correta quando uma alteração de conteúdo aparece imediatamente, o cache pode ser invalidado e um fallback existe. Redis não substitui o banco nem o cache de página.

Veja a infraestrutura: VPS para WordPress no Brasil para colocar este projeto no ar.

Diferencie as camadas

Cache de página armazena a resposta HTML; cache de objetos guarda objetos e resultados usados pelo PHP. CDN, navegador e proxy são camadas diferentes. Misturar os sintomas leva a limpar o componente errado. Comece identificando qual camada está servindo o conteúdo antigo.

Prepare Redis com isolamento

Mantenha Redis em rede privada, com autenticação e limite de memória adequado. Para vários sites, use bancos lógicos ou, melhor, namespaces/prefixos diferentes conforme o plugin. Não permita que um WordPress apague chaves de outro.

Confira conectividade a partir do host da aplicação:

redis-cli -h redis -a 'SENHA_FORA_DO_HISTORICO' ping

Não coloque a senha diretamente no shell em produção; o trecho serve para explicar o teste. Prefira secret manager ou ambiente controlado.

Configure e teste no WordPress

Instale um plugin de object cache mantido e confirme o host, porta, prefixo e TLS quando aplicável. Depois publique uma alteração pequena e observe:

1. a alteração aparece no painel;
2. a página pública mostra o novo valor;
3. o cache é invalidado;
4. uma segunda visita pode usar o objeto atualizado.

Faça o teste com conteúdo de homologação antes de editar uma página comercial.

Diagnóstico de dado antigo

Compare resposta do origin e resposta pública. Se o origin está novo e o navegador antigo, limpe a camada de página/CDN. Se o PHP lê valor antigo do Redis, invalide o grupo correto e confira prefixo. Se o Redis reinicia sem persistência, avalie se o conteúdo é reconstruível e configure o comportamento esperado.

Operação e rollback

Monitore memória, evictions, conexões e latência. Se o cache causar erro, desative o plugin ou troque o backend temporariamente sem apagar dados do banco. Veja hospedagem para WordPress e mantenha o ambiente com espaço para banco, uploads e logs.

Checklist

• [ ] Camadas de cache identificadas.
• [ ] Redis não está público.
• [ ] Prefixo isolado por site.
• [ ] Alteração e invalidação testadas.
• [ ] Fallback documentado.

FAQ

Redis deixa o WordPress sempre mais rápido?

Não. Ele ajuda em consultas repetidas, mas pode adicionar complexidade e consumir memória.

Posso apagar todas as chaves para corrigir conteúdo antigo?

Em teste, pode ser útil; em produção, identifique o namespace e o impacto antes de limpar.

Sinais de que o cache não é o problema

Se o origin entrega conteúdo antigo, investigue publicação, banco e plugin antes de limpar Redis. Se apenas usuários anônimos veem a versão velha, compare cache de página, CDN e cabeçalhos. Se o painel retorna erro de conexão, valide host, porta, autenticação e rede do container. Documente o caminho de fallback para que uma indisponibilidade de Redis degrade o WordPress de modo controlado, em vez de transformar o cache em dependência única.