Reduzca el trabajo repetido de la base de datos con una caché Redis local. Redis puede almacenar en memoria resultados reutilizables de la aplicación para que esta no tenga que regenerarlos en cada solicitud. El beneficio depende de lo que almacene en caché, de la frecuencia con la que se reutilice y del resto de su stack, no de un porcentaje de aceleración universal.
Esta guía cubre una única instancia de Redis en el mismo VPS Debian o Ubuntu que su aplicación, instalada desde los repositorios de la distribución y accesible únicamente por loopback. Incluye una pequeña comprobación funcional, una configuración de caché de objetos para WordPress y un ejemplo independiente con Node.js. No es una guía de despliegue con acceso remoto, alta disponibilidad o base de datos duradera.
Antes de empezar: decida qué almacenará Redis
Una caché reconstruible contiene datos que su aplicación puede recrear a partir de su base de datos de referencia o de otra fuente. Los fallos de caché, la caducidad, la expulsión de claves y los reinicios deben ser seguros: la aplicación debe obtener los datos originales y reconstruir la caché. Defina TTL e reglas de invalidación adecuados y evite servir datos privados en caché al usuario equivocado.
Las sesiones, las tareas en cola y los registros de referencia pueden tener requisitos distintos de pérdida y recuperación. No los mezcle en una instancia que pueda expulsar cualquier clave. Use una instancia de Redis aparte y una estrategia de persistencia, copias de seguridad y recuperación diseñada deliberadamente cuando los datos deban sobrevivir a los fallos. Redis Pub/Sub no es una cola de tareas duradera.
La documentación de expulsión de Redis explica por qué allkeys-lru puede eliminar cualquier clave. Por el contrario, noeviction hace que las escrituras afectadas fallen al llegar al límite de memoria; no proporciona copias de seguridad ni durabilidad.
Requisitos previos y alcance
- Una versión compatible de Debian o Ubuntu con systemd, acceso SSH y privilegios de sudo.
- Un VPS de pruebas recién instalado o una ventana de mantenimiento aprobada. Compruebe si ya existe un servicio Redis y qué aplicaciones dependen de él antes de cambiar nada.
- RAM y capacidad de disco dimensionadas para su carga de trabajo, incluidos el sistema operativo, la base de datos, PHP o Node.js, la sobrecarga de Redis y cualquier operación de persistencia. No existe una fórmula de RAM para un VPS que sea segura en todos los casos.
- Una aplicación en el mismo host. Los contenedores tienen sus propios espacios de nombres de red:
127.0.0.1dentro de un contenedor normalmente no se refiere al host.
Los pasos siguientes son un procedimiento que debe validar en la versión que elija, no una afirmación de que la instalación se haya probado en todas las versiones de Debian o Ubuntu. Las versiones de los paquetes varían según la distribución; esta guía no promete una versión concreta del servidor Redis.
Paso 1: instale los paquetes de la distribución
Actualice el índice de paquetes y, a continuación, inspeccione los paquetes candidatos y el origen de sus repositorios:
sudo apt update
apt-cache policy redis-server redis-tools
Continúe solo si los candidatos proceden de los repositorios de Debian o Ubuntu que usted pretende utilizar. Si ya hay configurado un repositorio de Redis de terceros, resuelva primero esa decisión de empaquetado. Esta guía no añade un repositorio de terceros ni realiza una actualización de paquetes de todo el sistema.
sudo apt install redis-server redis-tools
systemctl status redis-server --no-pager
systemctl cat redis-server
redis-server --version
redis-cli --version
Revise los cambios que propone APT antes de confirmar. Los paquetes pueden iniciar Redis automáticamente. La unidad de servicio muestra qué archivo de configuración se carga; la ruta habitual es /etc/redis/redis.conf, tal como documentan el manual de Redis de Debian y el manual de Redis de Ubuntu. Si la unidad o la ruta difieren, utilice la configuración realmente instalada en lugar de crear una segunda instancia.
Paso 2: mantenga Redis en local y proteja el acceso
Haga una copia de seguridad de la configuración antes de editarla. En una instalación nueva que use la ruta habitual:
sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.before-local-cache
sudoedit /etc/redis/redis.conf
Actualice las directivas existentes en lugar de añadir duplicados a ciegas. Para la configuración solo con loopback IPv4 que se usa en toda esta guía:
bind 127.0.0.1
protected-mode yes
Compruebe los archivos incluidos y las opciones de línea de comandos del servicio por si hubiera sobrescrituras. Si mantiene intencionadamente el loopback IPv6, verifique que sea solo ::1 y no un listener IPv6 en todas las interfaces. No enlace a 0.0.0.0 ni a ::.
No abra el puerto 6379 a internet. Revise tanto el firewall del host como cualquier firewall del proveedor. Si UFW está instalado, sudo ufw status verbose puede mostrar sus reglas actuales; no active ni reconfigure un firewall a ciegas a través de SSH. El loopback reduce la exposición de red, pero no aísla Redis de otros procesos locales. Una contraseña no sustituye las restricciones de red, y AUTH no cifra el tráfico, tal como explica la guía de seguridad de Redis.
Autenticación y secretos
Para una instancia dedicada a una sola aplicación, puede configurar la directiva requirepass existente con un secreto robusto y único. Establézcalo con un editor protegido o con el mecanismo de secretos de su herramienta de gestión de configuración; no pegue secretos reales en comandos de terminal, grabaciones, control de versiones ni en este tutorial. Restrinja el acceso al archivo de configuración al administrador y a la cuenta de servicio de Redis.
Si activa la autenticación, proporcione ese mismo secreto a cada cliente antes de activar la integración. Los ejemplos siguientes usan el modelo predeterminado de usuario y contraseña; los usuarios ACL con nombre necesitan ajustes de cliente equivalentes y permisos revisados. El aislamiento multiinquilino, el acceso remoto, el diseño de ACL y TLS requieren un diseño de despliegue independiente.
Paso 3: elija la memoria de la caché y los ajustes de persistencia
Establezca un maxmemory finito adecuado a su capacidad y carga de trabajo reales. Por ejemplo, lo siguiente es solo una ilustración de configuración, no una recomendación de dimensionamiento:
maxmemory 256mb
maxmemory-policy allkeys-lru
Use esta política de expulsión solo para datos de caché reconstruibles. maxmemory no es un límite estricto de la memoria total del proceso de Redis: la sobrecarga del asignador, algunos búferes y la actividad de persistencia pueden requerir un margen adicional. Mida la memoria residente de Redis y la presión global sobre el host junto con el uso de la aplicación.
Decida la persistencia por separado. Una caché desechable puede no necesitar persistencia en disco, siempre que la aplicación tolere un reinicio en frío. Si elige deliberadamente no usar persistencia en una instancia nueva solo de caché, los ajustes pertinentes son:
save ""
appendonly no
No aplique estos ajustes a una instancia que contenga datos que necesite conservar. La persistencia puede reducir el trabajo de calentamiento de la caché, pero las instantáneas RDB y AOF tienen compromisos distintos. Activar AOF no es una garantía absoluta de durabilidad, y los archivos de persistencia no sustituyen a las copias de seguridad fuera del host ni a una recuperación probada.
Aplique la configuración revisada durante una ventana de mantenimiento adecuada:
sudo systemctl restart redis-server
systemctl is-active redis-server
sudo ss -lntp '( sport = :6379 )'
Compruebe que el listener sea 127.0.0.1:6379, sin ningún listener público ni en todas las interfaces. Si el servicio falla o el listener es inesperado, deténgase aquí e inspeccione sudo journalctl -u redis-server -n 50 --no-pager. Trate los logs como potencialmente sensibles. No resuelva un problema de conexión local abriendo un puerto público.
Paso 4: realice una pequeña comprobación funcional
En su instancia de pruebas, abra una sesión local de la CLI. Si la autenticación está activada, use el aviso de contraseña:
redis-cli -h 127.0.0.1 -p 6379 --askpass
En una instancia de pruebas local sin autenticación configurada, omita --askpass. Dentro de la CLI, use una clave de demostración sin utilizar:
PING
SET sharpheberg:demo:cli hello EX 60
GET sharpheberg:demo:cli
TTL sharpheberg:demo:cli
DEL sharpheberg:demo:cli
EXIT
El comportamiento esperado (no una salida de prueba grabada) es PONG para PING, OK para SET y hello para GET antes de que caduque. TTL debería ser positivo si se consulta de inmediato; -2 significa que la clave ya no existe y -1 que no tiene caducidad. DEL devuelve 1 si la clave seguía existiendo, o 0 si ya había caducado. Esto demuestra el acceso básico a los comandos, no cargas de página más rápidas ni el rendimiento del hosting.
Paso 5: conecte su aplicación
WordPress: caché de objetos persistente, no caché de página completa
El plugin Redis Object Cache proporciona un backend persistente para la API de caché de objetos de WordPress. “Persistente” significa aquí que los objetos en caché pueden reutilizarse entre solicitudes de PHP; no significa que la persistencia en disco de Redis esté activada. El plugin no almacena automáticamente en caché todas las consultas SQL ni genera una caché HTML de página completa.
- Haga una copia de seguridad de su configuración de WordPress y compruebe si ya hay instalado un drop-in de caché de objetos.
- Instale y active Redis Object Cache primero en un sitio de staging.
- Proporcione la contraseña de Redis a través del mecanismo de gestión de secretos del entorno de ejecución de PHP. En el ejemplo siguiente, la variable de entorno se llama
REDIS_PASSWORD; WordPress la recibe mediante la constanteWP_REDIS_PASSWORD. - Añada lo siguiente al
wp-config.phpreal de su sitio, antes de que WordPress carguewp-settings.php. Use un prefijo exclusivo de este sitio.
$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 ejemplo con autenticación falla deliberadamente de forma clara si falta el secreto; configure primero el entorno de ejecución y valide en staging para no interrumpir un sitio en producción. Un export de shell por sí solo normalmente no hace que la variable esté disponible para PHP-FPM o Apache. Aprovisiónela explícitamente en el pool de workers de PHP o en el servicio correcto mediante una configuración protegida o una integración de secretos, y recargue después ese entorno de ejecución según sea necesario. Asegúrese de que WP-CLI reciba el mismo secreto cuando se utilice. No exponga los valores del entorno mediante páginas de depuración públicas ni logs.
Si su instancia aislada de Redis no tiene autenticación de forma intencionada, omita tanto el bloque de carga de la contraseña como WP_REDIS_PASSWORD; no sustituya un secreto vacío en el ejemplo con autenticación. Para un usuario ACL, siga el formato de usuario y contraseña documentado por el plugin.
Abra Ajustes → Redis, active la caché de objetos y verifique tanto el estado de conexión como que el drop-in esté activo. Consulte las opciones de configuración y las instrucciones de instalación de los responsables para su versión instalada. Un prefijo único y una base de datos seleccionada ayudan a evitar colisiones; no son límites de seguridad, y el comportamiento del vaciado de la caché debe revisarse antes de compartir una instancia entre sitios.
Pruebe el comportamiento con sesión iniciada y sin ella, la invalidación de la caché y la respuesta de la aplicación cuando Redis no está disponible. La caché de página completa es una capa aparte con sus propios requisitos de compatibilidad e invalidación.
Node.js: un ejemplo independiente con node-redis v5
Use una versión compatible de Node.js con el paquete. En su aplicación o en un directorio de demostración aparte, instale la versión mayor v5 y anote la versión resuelta:
npm install redis@5
npm ls redis
Conserve el lockfile generado para garantizar la repetibilidad. Guarde lo siguiente como node-example.cjs. Espera a la conexión real, usa una clave con caducidad exclusiva de esta ejecución, verifica su valor y su TTL, y elimina solo esa clave de demostración. No depende de una base de datos imaginaria.
'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;
});
Ejecute node node-example.cjs. La URL predeterminada es redis://127.0.0.1:6379. Para una instancia con autenticación, inyecte REDIS_URL mediante su entorno de ejecución o su gestor de secretos; su formato admite un usuario y una contraseña, cuyos caracteres reservados deben codificarse como URL. No escriba una URL con credenciales en el historial del shell, no la suba a un repositorio ni la imprima. Mantenga el destino en local para esta guía.
La guía de migración de node-redis v5 documenta close() como sustituto de quit() y destroy() como el método de desconexión inmediata. Aquí el cliente se cierra tras los comandos con await y se destruye si la limpieza no puede completarse con normalidad. La reconexión automática está desactivada en esta comprobación breve para que un servidor inaccesible no provoque reintentos de conexión interminables. Las aplicaciones en producción necesitan sus propias políticas de reintento, tiempo de espera, alternativa a la caché y apagado. La documentación de uso del cliente cubre las URL de conexión y los eventos de error.
Alcance de la comprobación funcional: el ciclo PING/SET/GET/TTL/DEL y el ejemplo de Node.js se comprobaron con Redis 8.0.2 en Debian 13 y node-redis 5.12.1 en un proceso desechable solo con loopback. Los paquetes se extrajeron en un directorio de pruebas, no se instalaron como servicio del host. Estas comprobaciones no validan todas las versiones de las distribuciones, la instalación con systemd, la integración con WordPress ni el rendimiento en producción.
Paso 6: monitorice la caché sin una prueba de carga
En una sesión local autenticada de la CLI, inspeccione estas secciones:
INFO stats
INFO memory
INFO clients
Los campos útiles incluyen keyspace_hits, keyspace_misses, evicted_keys, expired_keys, used_memory_human, used_memory_rss y connected_clients. No hay un campo genérico hit_rate que extraer de INFO.
Para un intervalo de observación definido, registre las variaciones de aciertos y fallos. Solo si su suma es positiva, calcule delta_hits / (delta_hits + delta_misses) × 100. Descarte los intervalos que crucen un reinicio de contadores o de la instancia. Es una proporción de búsquedas de claves de toda la instancia, no una tasa de aciertos de caché de página ni una medida directa de la reducción de consultas SQL.
Mida los tiempos de respuesta de la aplicación, la carga de la base de datos, los errores y el uso de recursos antes y después de la integración con un tráfico comparable. Distinga entre cachés frías y calientes y documente las versiones y las condiciones. Una prueba sintética de rendimiento de SET/GET no puede establecer la velocidad de página de WordPress, y ni un PING correcto ni esta demostración prueban ningún SLA de hosting.
Solución de problemas y ajustes avanzados opcionales
- Conexión rechazada: compruebe el estado del servicio, los logs, la dirección y el puerto de enlace reales, y si la aplicación está en un contenedor. Mantenga el diseño solo con loopback; no añada una excepción pública en el firewall.
- Fallo de autenticación: confirme que la aplicación recibe el secreto correcto y usa el usuario de Redis adecuado. No revele contraseñas mientras depura.
- Faltan claves en la caché: compruebe los TTL, la invalidación, los contadores de expulsión, los prefijos y la selección de base de datos. Los fallos de caché deben ser seguros para los datos reconstruibles.
- Presión de memoria: inspeccione la memoria residente de Redis, la memoria del host, la expulsión y el comportamiento de la aplicación. Revise el dimensionamiento en lugar de tratar un
maxmemorymayor como una solución automática. - Operaciones lentas: evite los escaneos amplios de claves y las tareas bloqueantes grandes en una instancia ocupada. Use SCAN incremental cuando sea necesario enumerar claves y considere UNLINK para eliminaciones grandes. No vacíe nunca datos compartidos como atajo de solución de problemas.
El ajuste del kernel no es un paso de instalación obligatorio. La guía de latencia de Redis recomienda desactivar las Transparent Huge Pages (THP). Si es relevante para su carga de trabajo medida, coordínelo con su proveedor o con el administrador del sistema operativo, utilice un método persistente compatible con la distribución y planifique un reinicio de Redis. Una escritura temporal en /sys no sobrevive a un reinicio. Revise por separado el overcommit y otros cambios de sysctl; no copie valores universales de backlog o de búferes de red en un VPS compartido.
Investigue los límites de descriptores de archivo solo si la demanda de conexiones observada o los errores lo justifican:
systemctl show redis-server -p LimitNOFILE
Para un Redis gestionado por systemd, use una sobrescritura [Service] revisada con un valor medido de LimitNOFILE= si es necesario, recargue después systemd y programe un reinicio controlado. Cambiar solo un ulimit de la shell o los límites de PAM no es suficiente para ese servicio. La documentación de límites de recursos de systemd explica los ajustes del servicio.
Planifique el despliegue de Redis en su VPS
Un despliegue útil de Redis empieza con una semántica de caché clara, acceso solo local, decisiones deliberadas sobre memoria y persistencia, y comprobaciones a nivel de aplicación. Mantenga separados sus datos de referencia y los datos desechables de la caché, y valide el beneficio con su propia carga de trabajo antes de escalar.
Compare los recursos y funciones que figuran actualmente en los planes de VPS Linux de SharpHeberg para elegir un entorno para su aplicación y su caché Redis local. Dimensione para el stack completo, mantenga margen de capacidad y valide la configuración en el sistema operativo que elija antes de un despliegue en producción.