Reduza o trabalho repetido da base de dados com uma cache Redis local. O Redis pode guardar em memória resultados reutilizáveis da aplicação, para que esta não tenha de os voltar a gerar a cada pedido. O benefício depende do que guarda em cache, da frequência com que é reutilizado e do resto da sua stack, e não de uma percentagem de aceleração universal.
Este guia abrange uma única instância Redis no mesmo VPS Debian ou Ubuntu da respetiva aplicação, instalada a partir dos repositórios da distribuição e acessível apenas através de loopback. Inclui uma pequena verificação funcional, uma configuração de cache de objetos para WordPress e um exemplo autónomo em Node.js. Não é um guia para acesso remoto, alta disponibilidade ou implementação de uma base de dados durável.
Antes de começar: decida o que o Redis vai armazenar
Uma cache reconstruível contém dados que a sua aplicação pode recriar a partir da base de dados de referência ou de outra fonte. As falhas de cache, a expiração, a remoção de chaves (eviction) e os reinícios têm de ser seguros: a aplicação deve obter os dados originais e reconstruir a cache. Defina TTLs e regras de invalidação adequados e evite servir dados privados em cache ao utilizador errado.
As sessões, as tarefas em fila e os registos de referência podem ter requisitos diferentes de perda e recuperação. Não os misture numa instância que possa remover qualquer chave. Utilize uma instância Redis separada e uma estratégia de persistência, cópia de segurança e recuperação deliberadamente concebida quando os dados tiverem de sobreviver a falhas. O Pub/Sub do Redis não é uma fila de tarefas durável.
A documentação de eviction do Redis explica por que razão a política allkeys-lru pode remover qualquer chave. Por outro lado, a política noeviction faz com que as escritas afetadas falhem no limite de memória; não fornece cópias de segurança nem durabilidade.
Pré-requisitos e âmbito
- Uma versão suportada de Debian ou Ubuntu com systemd, acesso SSH e privilégios sudo.
- Um VPS de teste novo ou uma janela de manutenção aprovada. Verifique se existe um serviço Redis e aplicações que dependam dele antes de alterar o que quer que seja.
- Capacidade de RAM e de disco dimensionada para a sua carga de trabalho, incluindo o sistema operativo, a base de dados, o PHP ou o Node.js, a sobrecarga do Redis e quaisquer operações de persistência. Não existe uma fórmula de RAM universalmente segura para VPS.
- Uma aplicação no mesmo anfitrião. Os contentores têm os seus próprios espaços de nomes de rede: o
127.0.0.1dentro de um contentor normalmente não se refere ao anfitrião.
Os passos abaixo são um procedimento a validar na versão que escolher, e não uma afirmação de que a instalação foi testada em todas as versões de Debian ou Ubuntu. As versões dos pacotes variam consoante a distribuição; este guia não promete uma versão específica do servidor Redis.
Passo 1: instale os pacotes da distribuição
Atualize o índice de pacotes e depois inspecione os pacotes candidatos e a origem dos seus repositórios:
sudo apt update
apt-cache policy redis-server redis-tools
Continue apenas se os candidatos provierem dos repositórios Debian ou Ubuntu pretendidos. Se já estiver configurado um repositório Redis de terceiros, resolva essa escolha de empacotamento antes de prosseguir. Este guia não adiciona um repositório de terceiros nem faz uma atualização de pacotes de todo o sistema.
sudo apt install redis-server redis-tools
systemctl status redis-server --no-pager
systemctl cat redis-server
redis-server --version
redis-cli --version
Reveja as alterações propostas pelo APT antes de confirmar. Os pacotes podem iniciar o Redis automaticamente. A unidade de serviço mostra qual o ficheiro de configuração carregado; o caminho habitual é /etc/redis/redis.conf, conforme documentado no manual do Redis no Debian e no manual do Redis no Ubuntu. Se a unidade ou o caminho forem diferentes, utilize a configuração efetivamente instalada em vez de criar uma segunda instância.
Passo 2: mantenha o Redis local e proteja o acesso
Faça uma cópia de segurança da configuração antes de a editar. Numa instalação nova que use o caminho habitual:
sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.before-local-cache
sudoedit /etc/redis/redis.conf
Atualize as diretivas existentes em vez de acrescentar duplicados às cegas. Para a configuração apenas com loopback IPv4 utilizada ao longo deste guia:
bind 127.0.0.1
protected-mode yes
Verifique se há substituições nos ficheiros incluídos e nas opções de linha de comandos do serviço. Se mantiver intencionalmente o loopback IPv6, confirme que é apenas ::1, e não um listener IPv6 em todas as interfaces. Não faça bind a 0.0.0.0 nem a ::.
Não abra a porta 6379 à internet pública. Reveja tanto a firewall do anfitrião como qualquer firewall do fornecedor. Se o UFW estiver instalado, sudo ufw status verbose pode mostrar as regras atuais; não ative nem reconfigure uma firewall às cegas por SSH. O loopback reduz a exposição de rede, mas não isola o Redis de outros processos locais. Uma palavra-passe não substitui as restrições de rede, e o AUTH não encripta o tráfego, como explica o guia de segurança do Redis.
Autenticação e segredos
Para uma instância dedicada a uma única aplicação, pode configurar a diretiva requirepass existente com um segredo forte e único. Defina-o através de um editor protegido ou do mecanismo de segredos da sua ferramenta de gestão de configuração; não cole segredos reais em comandos de terminal, gravações, controlo de versões ou neste tutorial. Restrinja o acesso ao ficheiro de configuração ao administrador e à conta de serviço do Redis.
Se ativar a autenticação, forneça esse mesmo segredo a cada cliente antes de ativar a integração. Os exemplos abaixo utilizam o modelo predefinido de utilizador/palavra-passe; os utilizadores ACL com nome precisam de definições de cliente correspondentes e de permissões revistas. O isolamento multi-tenant, o acesso remoto, a conceção de ACL e o TLS exigem um desenho de implementação à parte.
Passo 3: escolha as definições de memória e persistência da cache
Defina um maxmemory finito, adequado à sua capacidade e carga de trabalho reais. Por exemplo, o seguinte é apenas uma ilustração de configuração, e não uma recomendação de dimensionamento:
maxmemory 256mb
maxmemory-policy allkeys-lru
Utilize esta política de eviction apenas para dados de cache reconstruíveis. O maxmemory não é um limite rígido para a memória total do processo Redis: a sobrecarga do alocador, alguns buffers e a atividade de persistência podem exigir margem adicional. Meça a memória residente do Redis e a pressão global sobre o anfitrião em conjunto com a utilização da aplicação.
Decida a persistência separadamente. Uma cache descartável pode não precisar de persistência em disco, desde que a aplicação tolere um arranque a frio. Se escolher deliberadamente não ter persistência numa nova instância apenas de cache, as definições relevantes são:
save ""
appendonly no
Não aplique estas definições a uma instância que contenha dados que precisa de preservar. A persistência pode reduzir o trabalho de aquecimento da cache, mas os snapshots RDB e o AOF têm compromissos diferentes. Ativar o AOF não é uma garantia absoluta de durabilidade, e os ficheiros de persistência não substituem cópias de segurança fora do anfitrião e uma recuperação testada.
Aplique a configuração revista durante uma janela de manutenção adequada:
sudo systemctl restart redis-server
systemctl is-active redis-server
sudo ss -lntp '( sport = :6379 )'
Confirme que o listener é 127.0.0.1:6379, sem nenhum listener público ou em todas as interfaces. Se o serviço falhar ou o listener for inesperado, pare aqui e inspecione sudo journalctl -u redis-server -n 50 --no-pager. Trate os registos como potencialmente sensíveis. Não resolva um problema de ligação local abrindo uma porta pública.
Passo 4: execute uma pequena verificação funcional
Na sua instância de teste, abra uma sessão CLI local. Se a autenticação estiver ativada, utilize o pedido de palavra-passe:
redis-cli -h 127.0.0.1 -p 6379 --askpass
Para uma instância de teste local sem autenticação configurada, omita --askpass. Dentro do CLI, utilize uma chave de demonstração não utilizada:
PING
SET sharpheberg:demo:cli hello EX 60
GET sharpheberg:demo:cli
TTL sharpheberg:demo:cli
DEL sharpheberg:demo:cli
EXIT
O comportamento esperado (e não um resultado de teste gravado) é PONG para o PING, OK para o SET e hello para o GET antes da expiração. O TTL deve ser positivo se verificado rapidamente; -2 significa que a chave já não existe e -1 significa que não tem expiração. O DEL devolve 1 se a chave ainda existia, ou 0 se já tinha expirado. Isto prova o acesso básico aos comandos, e não carregamentos de página mais rápidos nem o desempenho do alojamento.
Passo 5: ligue a sua aplicação
WordPress: cache de objetos persistente, não cache de página completa
O plugin Redis Object Cache fornece um backend persistente para a API de cache de objetos do WordPress. “Persistente” significa aqui que os objetos em cache podem ser reutilizados entre pedidos PHP; não significa que a persistência em disco do Redis esteja ativada. O plugin não coloca automaticamente em cache todas as consultas SQL nem produz uma cache HTML de página completa.
- Faça uma cópia de segurança da configuração do WordPress e verifique se já existe um drop-in de cache de objetos instalado.
- Instale e ative o Redis Object Cache primeiro num site de staging.
- Forneça a palavra-passe do Redis através do mecanismo de gestão de segredos do seu runtime PHP. No exemplo abaixo, a variável de ambiente chama-se
REDIS_PASSWORD; o WordPress recebe-a através da constanteWP_REDIS_PASSWORD. - Adicione o seguinte ao
wp-config.phpreal do seu site, antes de o WordPress carregar owp-settings.php. Utilize um prefixo exclusivo deste site.
$redisPassword = getenv('REDIS_PASSWORD');
if ($redisPassword === false || $redisPassword === '') {
throw new RuntimeException('Redis secret is not available to PHP.');
}
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'example-site:');
define('WP_REDIS_PASSWORD', $redisPassword);
unset($redisPassword);
Este exemplo autenticado falha intencionalmente de forma clara se o segredo estiver em falta; configure primeiro o runtime e valide em staging para evitar interromper um site em produção. Um simples export na shell normalmente não torna a variável disponível ao PHP-FPM ou ao Apache. Disponibilize-a explicitamente ao pool de workers PHP ou ao serviço correto, através de uma configuração protegida ou de uma integração de segredos, e depois recarregue esse runtime conforme necessário. Garanta que o WP-CLI recebe o mesmo segredo quando for utilizado. Não exponha valores de ambiente em páginas de depuração públicas nem em registos.
Se a sua instância Redis isolada não tiver intencionalmente autenticação, omita tanto o bloco de carregamento da palavra-passe como o WP_REDIS_PASSWORD; não substitua por um segredo vazio no exemplo autenticado. Para um utilizador ACL, siga o formato de utilizador/palavra-passe documentado pelo plugin.
Abra Settings → Redis, ative a cache de objetos e verifique tanto o estado de ligação como a existência de um drop-in ativo. Consulte as opções de configuração e as instruções de instalação dos responsáveis para a sua versão instalada. Um prefixo único e uma base de dados selecionada ajudam a evitar colisões; não são fronteiras de segurança, e o comportamento de limpeza da cache (flush) tem de ser revisto antes de partilhar uma instância entre sites.
Teste o comportamento com sessão iniciada e sem sessão, a invalidação da cache e a resposta da aplicação quando o Redis não está disponível. A cache de página completa é uma camada separada, com os seus próprios requisitos de compatibilidade e invalidação.
Node.js: um exemplo autónomo com node-redis v5
Utilize uma versão suportada do Node.js compatível com o pacote. Na sua aplicação ou num diretório de demonstração separado, instale a versão principal v5 e registe a versão resolvida:
npm install redis@5
npm ls redis
Mantenha o ficheiro de lock gerado para garantir repetibilidade. Guarde o seguinte como node-example.cjs. Aguarda a ligação efetiva, utiliza uma chave com expiração exclusiva desta execução, verifica o seu valor e TTL e elimina apenas essa chave de demonstração. Não depende de uma base de dados imaginária.
'use strict';
const { createClient } = require('redis');
const { randomUUID } = require('node:crypto');
const assert = require('node:assert/strict');
async function main() {
const client = createClient({
url: process.env.REDIS_URL || 'redis://127.0.0.1:6379',
socket: { connectTimeout: 5000, reconnectStrategy: false }
});
client.on('error', () => console.error('Redis client error; check service and connection settings.'));
const key = `sharpheberg:demo:node:${randomUUID()}`;
try {
await client.connect();
assert.equal(await client.set(key, 'hello', { EX: 60 }), 'OK');
const value = await client.get(key);
assert.equal(value, 'hello');
const ttl = await client.ttl(key);
assert.ok(ttl > 0 && ttl <= 60, 'Demo key must have a positive TTL');
console.log('GET:', value);
console.log('TTL (seconds):', ttl);
assert.equal(await client.del(key), 1);
assert.equal(await client.get(key), null);
console.log('Demo key deleted.');
} finally {
if (client.isReady) {
try {
await client.del(key);
await client.close();
} finally {
if (client.isOpen) client.destroy();
}
} else if (client.isOpen) {
client.destroy();
}
}
}
main().catch(() => {
console.error('Redis demo failed; no credentials are printed.');
process.exitCode = 1;
});
Execute node node-example.cjs. O URL predefinido é redis://127.0.0.1:6379. Para uma instância autenticada, injete o REDIS_URL através do seu runtime ou gestor de segredos; o seu formato suporta nome de utilizador e palavra-passe, cujos carateres reservados têm de ser codificados em URL. Não escreva um URL com credenciais no histórico da shell, não o submeta ao controlo de versões nem o imprima. Mantenha o destino local neste guia.
O guia de migração do node-redis v5 documenta o close() como substituto do quit() e o destroy() como método de desligação imediata. Aqui, o cliente fecha após os comandos aguardados e é destruído se a limpeza não puder terminar normalmente. A religação automática está desativada nesta verificação curta, para que um servidor inacessível não desencadeie tentativas de ligação infinitas. As aplicações em produção precisam das suas próprias políticas de repetição, timeout, fallback de cache e encerramento. A documentação de utilização do cliente aborda os URLs de ligação e os eventos de erro.
Âmbito da verificação funcional: o ciclo PING/SET/GET/TTL/DEL e o exemplo Node.js foram verificados com o Redis 8.0.2 no Debian 13 e com o node-redis 5.12.1, num processo descartável apenas com loopback. Os pacotes foram extraídos para um diretório de teste, e não instalados como serviço do anfitrião. Estas verificações não validam todas as versões de distribuições, instalações systemd, integrações WordPress nem o desempenho em produção.
Passo 6: monitorize a cache sem um teste de carga
Numa sessão CLI local autenticada, inspecione estas secções:
INFO stats
INFO memory
INFO clients
Os campos úteis incluem keyspace_hits, keyspace_misses, evicted_keys, expired_keys, used_memory_human, used_memory_rss e connected_clients. Não existe um campo genérico hit_rate para extrair do INFO.
Para um intervalo de observação definido, registe as variações de hits e misses. Só se a sua soma for positiva, calcule delta_hits / (delta_hits + delta_misses) × 100. Descarte os intervalos que atravessem um reset dos contadores ou um reinício. Este é um rácio de consultas de chaves ao nível da instância, não um rácio de acertos de cache de página nem uma medida direta da redução de consultas SQL.
Meça os tempos de resposta da aplicação, a carga da base de dados, os erros e a utilização de recursos antes e depois da integração, sob tráfego comparável. Distinga caches frias de caches quentes e documente versões e condições. Um teste sintético de débito SET/GET não pode determinar a velocidade de páginas WordPress, e nem um PING bem-sucedido nem esta demonstração provam qualquer SLA de alojamento.
Resolução de problemas e afinação avançada opcional
- Ligação recusada: verifique o estado do serviço, os registos, o endereço e a porta de bind efetivos e se a aplicação está num contentor. Mantenha a conceção apenas com loopback; não adicione uma exceção pública na firewall.
- Falha de autenticação: confirme que a aplicação recebe o segredo pretendido e utiliza o utilizador Redis correto. Não revele palavras-passe durante a depuração.
- Chaves de cache em falta: verifique os TTLs, a invalidação, os contadores de eviction, os prefixos e a seleção da base de dados. As falhas de cache devem ser seguras para dados reconstruíveis.
- Pressão de memória: inspecione a memória residente do Redis, a memória do anfitrião, o eviction e o comportamento da aplicação. Reveja o dimensionamento em vez de tratar um
maxmemorymaior como uma correção automática. - Operações lentas: evite varrimentos amplos de chaves e trabalho de bloqueio pesado numa instância ocupada. Utilize o SCAN incremental quando for necessário enumerar e considere o UNLINK para eliminações grandes. Nunca limpe dados partilhados como atalho de resolução de problemas.
A afinação do kernel não é um passo de instalação obrigatório. A orientação sobre latência do Redis recomenda desativar as Transparent Huge Pages (THP). Se for relevante para a sua carga de trabalho medida, combine-o com o administrador do anfitrião ou do SO, utilize um método persistente suportado pela distribuição e planeie um reinício do Redis. Uma escrita temporária em /sys não sobrevive ao reinício. Reveja separadamente o overcommit e outras alterações de sysctl; não copie valores universais de backlog ou de buffers de rede para um VPS partilhado.
Investigue os limites de descritores de ficheiros apenas se a procura de ligações observada ou os erros o justificarem:
systemctl show redis-server -p LimitNOFILE
Para o Redis gerido pelo systemd, utilize, se necessário, um override de [Service] revisto com um valor medido de LimitNOFILE=, depois recarregue o systemd e agende um reinício controlado. Alterar apenas um ulimit da shell ou os limites do PAM não é suficiente para esse serviço. A documentação de limites de recursos do systemd explica as definições do serviço.
Planeie a sua implementação do Redis num VPS
Uma boa implementação do Redis começa com uma semântica de cache clara, acesso apenas local, escolhas deliberadas de memória e persistência e verificações ao nível da aplicação. Mantenha os seus dados de referência separados dos dados de cache descartáveis e valide o benefício com a sua própria carga de trabalho antes de escalar.
Compare os recursos e as funcionalidades atualmente listados nos planos VPS Linux da SharpHeberg para escolher um ambiente para a sua aplicação e a sua cache Redis local. Dimensione para toda a stack, mantenha margem de capacidade e valide a configuração no sistema operativo escolhido antes de um lançamento em produção.