Bases de datos: Parte 5 — Redis y Valkey

Redis (Remote Dictionary Server) — un almacén de datos tipo «clave — valor» que mantiene todos los datos en la memoria RAM. Gracias a esto, las operaciones se realizan en fracciones de milisegundo. Redis rara vez sirve como la base de datos principal de una aplicación: normalmente funciona junto a PostgreSQL o MySQL y asume tareas donde la velocidad es importante — caché, sesiones, colas, contadores.

El valor en Redis puede ser no solo una cadena, sino una estructura de datos: lista, conjunto, hash, conjunto ordenado, stream (flujo), array de bits, HyperLogLog para el conteo aproximado de valores únicos, índice geo. Para cada estructura hay comandos atómicos propios, por lo que muchas tareas se resuelven con un solo comando sin bloqueos en la aplicación.

Licencia: qué cambió desde 2024

Hasta la primavera de 2024 Redis se distribuía bajo la licencia libre BSD. De ahí proviene la confusión en artículos y documentación antiguos.

• Marzo de 2024, Redis 7.4. La empresa Redis cambió el proyecto a dos licencias a elegir — RSALv2 y SSPLv1. Ambas restringen la provisión de Redis como servicio en la nube y no son reconocidas como open source por la Open Source Initiative (OSI).
• Marzo de 2024, Valkey. En respuesta, la comunidad bajo el paraguas de la Linux Foundation creó el fork Valkey basado en la última versión bajo BSD (7.2.4). Valkey permanece bajo licencia BSD y se desarrolla de forma independiente; en septiembre de 2026 la rama vigente es la 9.x.
• Mayo de 2025, Redis 8. A las dos licencias se añadió una tercera — AGPLv3, aprobada por la OSI. Redis 8 vuelve a poder utilizarse como software abierto, pero AGPL exige revelar el código fuente de la versión modificada si se ofrece a usuarios a través de la red.

Para la mayoría de las empresas que usan Redis dentro de su producto como caché o almacén de sesiones, ninguna de estas licencias supone un obstáculo. Conviene estudiar la licencia con detenimiento si se ofrece Redis a clientes como servicio o se distribuye una versión modificada. Si se necesita una licencia permisiva sin condiciones, se elige Valkey: es compatible con Redis en protocolo y comandos de las versiones 7.2, y las bibliotecas cliente existentes funcionan con él sin cambios.

Qué trae Redis 8

Antes las capacidades avanzadas se ofrecían por separado — como módulos y la compilación Redis Stack. En Redis 8 están incluidas en la versión principal:

• Redis Query Engine — índices secundarios, búsqueda de texto completo y búsqueda vectorial (el antiguo módulo RediSearch);
• JSON — almacenamiento y modificación de documentos JSON por campos;
• Time Series — series temporales;
• estructuras probabilísticas — filtros Bloom, Count-Min Sketch, Top-K y otras;
• vector sets — nuevo tipo de datos para búsqueda vectorial.

En Valkey parte de estas funcionalidades se desarrolla como módulos separados; antes de migrar conviene comprobar cuáles necesita tu aplicación.

Escenarios principales

Caché. La aplicación guarda en Redis los resultados de consultas costosas a la base de datos principal o fragmentos de página listos y, en una nueva petición, los toma de la memoria. Para el caché se fija un límite de memoria y una política de expulsión de claves antiguas:

maxmemory 512mb
maxmemory-policy allkeys-lru

Sesiones de usuarios. El identificador de sesión es la clave, los datos de sesión son el valor con tiempo de vida limitado (SET session:abc ... EX 3600). Varios servidores de la aplicación ven las mismas sesiones.

Colas de tareas. Listas (LPUSH/BRPOP) y streams (XADD/XREADGROUP) se usan como un broker de mensajes simple. Sobre ellos se construyen, por ejemplo, las colas Sidekiq en Ruby y RQ en Python; Celery puede usar Redis como broker. El mecanismo PUBLISH/SUBSCRIBE sirve para notificaciones en tiempo real, pero los mensajes no se guardan: si un suscriptor estuvo desconectado, no los recibirá.

Contadores y rankings. INCR incrementa de forma atómica un contador de visualizaciones o intentos de acceso, y los conjuntos ordenados (ZADD, ZRANGE) permiten mantener una tabla de líderes sin recálculos.

Limitación de la tasa de peticiones. Un contador con tiempo de vida es la forma estándar de limitar el número de solicitudes a una API desde una dirección o un usuario.

Guardado de datos en disco

Aunque Redis funciona en memoria, los datos se pueden guardar en disco y restaurar tras un reinicio. Existen dos mecanismos.

RDB — snapshots. En intervalos dados Redis escribe una copia completa de los datos en el archivo dump.rdb. El archivo es compacto, conveniente para copias de seguridad y se carga rápido. La desventaja: ante una parada inesperada se pierden los cambios desde el último snapshot — normalmente unos minutos.

save 3600 1 300 100 60 10000   # instantánea: si en una hora cambió 1 clave, en 5 minutos — 100, en un minuto — 10 000

AOF — registro de operaciones. Cada comando que modifica se añade al registro, que se reproduce al arrancar. Con la configuración por defecto appendfsync everysec en caso de fallo se pierde como mucho un segundo de escrituras.

appendonly yes
appendfsync everysec

La documentación de Redis recomienda activar ambos mecanismos si se desea una persistencia comparable a PostgreSQL. Si Redis se usa solo como caché, el guardado puede desactivarse por completo (save "", appendonly no) — los datos los rellenará de nuevo la aplicación.

Para una copia de seguridad basta con copiar el archivo RDB: Redis lo crea con un nombre temporal y lo renombra de forma atómica, por lo que copiar el archivo en tiempo de ejecución es seguro.

Seguridad: configuración básica

Redis está pensado para funcionar dentro de una red de confianza y no debe estar accesible desde Internet. Un solo comando FLUSHALL borra todos los datos, y mediante CONFIG un atacante puede escribir un archivo en un directorio arbitrario del servidor. Instancias de Redis abiertas externamente son detectadas y atacadas constantemente por escáneres automáticos.

La configuración mínima segura redis.conf para un servidor donde Redis lo usa solo una aplicación local:

bind 127.0.0.1 -::1
protected-mode yes
port 6379

# отключаем пользователя по умолчанию и создаём отдельного для приложения
user default off
user app on >очень-длинный-случайный-пароль ~* &* +@all -@dangerous

Qué ocurre aquí:

• bind — Redis acepta conexiones solo desde la dirección local. Si la aplicación está en otro servidor, indica la dirección interna de la red privada, no la pública;
• protected-mode yes — desde la versión 3.2 Redis, sin contraseña y con bind en todas las interfaces, responde únicamente a clientes locales;
• user ... -@dangerous — las listas de control de acceso (ACL, aparecieron en Redis 6) prohíben al usuario de la aplicación comandos peligrosos: FLUSHALL, CONFIG, KEYS, DEBUG y otros. En esta categoría también entran INFO, CLIENT y SORT; si la aplicación o su biblioteca usan alguno de ellos, permite explícitamente los comandos necesarios, por ejemplo +info. Para una instalación muy simple se puede limitar a una contraseña general requirepass, pero las ACL son más flexibles.

Además, el puerto 6379 debe cerrarse con un cortafuegos, y Redis debe ejecutarse con un usuario no privilegiado separado, no como root.

Errores típicos

• Puerto expuesto al exterior por Docker. La línea -p 6379:6379 en docker run o ports: - "6379:6379" en Compose publica el puerto en todas las interfaces del servidor, y Docker añade sus reglas de iptables que evitan ufw. En la imagen oficial de Redis el modo protegido está desactivado por defecto. Si Redis solo lo necesitan contenedores vecinos, no es necesario publicar el puerto; para acceso desde el host — 127.0.0.1:6379:6379.
• No hay límite de memoria. Sin maxmemory el caché crece hasta agotar la RAM, y el mecanismo del sistema OOM mata el proceso.
• Comando KEYS * en una base en producción. Recorre todas las claves y bloquea el servidor durante el recorrido. Para iterar claves se usa SCAN.
• Redis como único almacén de datos importantes sin AOF. Al reiniciar se pierde todo lo que no entró en el último snapshot.

Ventajas

• Velocidad. Latencias de fracciones de milisegundo, cientos de miles de operaciones por segundo en una sola instancia.
• Estructuras de datos. Muchas tareas se resuelven con comandos ya disponibles sin código adicional.
• Atomicidad. Los comandos se ejecutan de forma secuencial, por eso contadores y colas funcionan correctamente sin bloqueos en la aplicación. Para varias operaciones seguidas hay transacciones MULTI/EXEC y scripts en Lua.
• Replicación y clúster. Réplicas para alta disponibilidad, Redis Sentinel para conmutación automática, Redis Cluster para distribuir datos entre nodos.
• Ecosistema. Hay bibliotecas cliente para todos los lenguajes populares.

Desventajas

• El volumen está limitado por la memoria. Todos los datos deben caber en la RAM, y esta es más cara que el disco.
• No hay consultas complejas. Joins y agregaciones arbitrarias, como en SQL, no existen. Query Engine en Redis 8 añade búsqueda por índices, pero no sustituye a una base relacional.
• La persistencia requiere configuración. Por defecto es posible perder datos de los últimos minutos.
• Los comandos se ejecutan en un solo hilo. Desde la versión 6.0 el E/S de red se puede distribuir en varios hilos (io-threads), pero los propios comandos aún se ejecutan secuencialmente, por lo que un comando lento retrasa a todos los demás.

Cuándo usarlo

Redis o Valkey son necesarios cuando la base de datos principal deja de poder con consultas iguales frecuentes, cuando se requiere un almacén de sesiones común para varios servidores o una cola de tareas simple y rápida. Guardar en ellos la única copia de datos cuya pérdida es inaceptable solo tiene sentido con AOF activado, replicación y copias de seguridad regulares. Para un proyecto pequeño con un solo servidor y carga moderada, el caché en la memoria de la propia aplicación o las consultas a una base bien indexada a menudo son suficientes, y no hace falta un Redis separado.