Cache com Redis: Acelerando Consultas Frequentes do Seu OT

Conforme um OTServer cresce, certas consultas ao banco de dados se repetem centenas de vezes por minuto — ranking de jogadores, informações de guild, dados que mudam pouco mas são lidos com muita frequência. É exatamente nesse cenário que um cache como o Redis entra.

O que é o Redis

Redis é um banco de dados em memória, extremamente rápido, usado como camada de cache na frente do MySQL. Em vez de bater no banco toda vez que alguém abre o ranking, por exemplo, você guarda o resultado já processado no Redis por um tempo determinado, e serve as próximas requisições direto da memória — ordens de magnitude mais rápido que uma query no disco.

O que vale a pena cachear

• Rankings (level, skill, PvP) — mudam pouco minuto a minuto, mas são consultados o tempo todo.
• Informações de guild — membros, nível da guild, que não mudam a cada segundo.
• Contadores públicos — jogadores online, total de contas registradas.
• Resultados de configuração — valores que vêm de uma tabela de configuração e raramente mudam.

O que NÃO vale a pena cachear

Dados que precisam de consistência imediata — saldo de coins, inventário, HP do personagem — não devem ir pro cache sem muito cuidado. Um cache desatualizado mostrando saldo errado, por exemplo, pode gerar confusão séria (ou até ser explorado).

Exemplo básico de uso

// Tenta pegar do cache primeiro
$ranking = $redis->get("ranking:level");

if ($ranking === false) {
    // Nao tinha no cache: busca no banco
    $ranking = buscarRankingDoBanco();

    // Guarda no cache por 5 minutos
    $redis->setex("ranking:level", 300, serialize($ranking));
} else {
    $ranking = unserialize($ranking);
}

O problema que todo mundo subestima: invalidação

"Tem duas coisas difíceis em computação: nomear variáveis e invalidar cache." A piada é clássica porque é verdadeira. Decidir quando um dado em cache deve ser atualizado (expirar por tempo, ou ser invalidado manualmente quando o dado-fonte muda) é onde a maioria dos bugs de cache aparece. Pra começar, cache com expiração por tempo (TTL) simples, tipo o exemplo acima, já evita 90% dos problemas — só ajuste o tempo de expiração de acordo com o quão "fresco" o dado precisa estar.

Se o seu servidor ainda é pequeno e o banco não está sofrendo com volume de queries, Redis é uma otimização prematura. Implemente quando sentir a dor real de performance — não antes.