Categoría: Bases de datos
Redis y Valkey gestionados: caché, colas y sesiones sin perder datos
La caché, las colas de trabajos y las sesiones de vuestra aplicación en un Redis o un Valkey que no se queda sin memoria, que conmuta solo si cae y que sabe qué datos puede perder y cuáles no.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Valkey: BSD 3-Clause. Redis 8: RSALv2, SSPLv1 o AGPLv3
En resumen
Redis es una base de datos en memoria de clave y valor que se usa como caché, cola y almacén de sesiones; Valkey es su bifurcación de código abierto bajo la Linux Foundation. Los instalamos y operamos en vuestra cuenta cloud: persistencia, réplicas con Sentinel o Cluster, límites de memoria, métricas y actualizaciones, todo descrito en código en vuestro repositorio.
¿Qué nos encargamos de mantener?
Redis suele entrar en un proyecto como «la caché» y acaba guardando sesiones, colas de trabajos, límites de peticiones y bloqueos. Cada uso necesita una configuración distinta, y el problema aparece cuando todos comparten la misma instancia con los ajustes por defecto.
Persistencia
RDB, AOF o ninguna, según lo que pase si se pierde el contenido.
Réplicas
Réplica asíncrona y conmutación con Sentinel o con el modo clúster.
Memoria
maxmemory, política de expulsión y fragmentación bajo control.
Métricas
redis_exporter en Prometheus: memoria, aciertos, latencia y réplica.
Accesos
ACL por aplicación, TLS y comandos peligrosos bloqueados.
En código
Configuración en Terraform o Ansible, en vuestro repositorio y documentada.
¿Qué arquitectura recomendamos?
La primera decisión es separar lo que se puede perder de lo que no. Una caché pura va en una instancia sin persistencia y con expulsión de las claves menos usadas. Las sesiones y las colas van en otra, con AOF y con la política noeviction: si se llena, Redis rechaza escrituras y salta una alerta, en vez de borrar en silencio trabajos pendientes.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Caché que se puede reconstruir | Un nodo, sin persistencia, allkeys-lru |
Lo más simple; si cae, la aplicación vuelve a la base de datos |
| Sesiones o colas en un solo servidor de datos | Principal, réplica y tres Sentinel, con AOF | Conmutación automática y pérdida acotada a un segundo |
| Datos que no caben en un nodo | Redis Cluster o Valkey en modo clúster | Reparte claves entre varios principales con sus réplicas |
| Proveedor con servicio gestionado | ElastiCache, Memorystore, Azure Managed Redis u otro | Menos piezas; nosotros ajustamos, vigilamos y probamos |
La réplica en Redis es asíncrona: una escritura confirmada puede perderse si el principal cae justo después. Si una operación concreta no lo tolera, usamos WAIT o la guardamos además en la base de datos principal.
¿Qué problemas encontramos más a menudo?
- Sin maxmemory: Redis crece hasta que el sistema lo mata por falta de memoria y se pierde todo de golpe.
- Política de expulsión equivocada: una cola con
allkeys-lruborra trabajos sin avisar cuando se llena. - Claves sin caducidad: la caché crece sin límite porque nadie puso tiempo de vida a las claves.
- Comandos que bloquean: un
KEYS *en producción o claves enormes que paran el servidor durante segundos. - Expuesto a internet: sin contraseña y en el puerto por defecto, uno de los fallos que más se aprovechan.
- Sentinel en dos máquinas: sin mayoría posible, la conmutación no ocurre o deja dos principales.
¿Cómo hacemos las copias y las actualizaciones?
Aunque uséis AOF, guardamos instantáneas RDB periódicas fuera del servidor, cifradas, en otra cuenta o en otro proveedor. La prueba consiste en arrancar una instancia aislada a partir de esa copia, comprobar el número de claves y leer algunas de control. El tiempo que tarda queda en el informe.
Para actualizar, empezamos por las réplicas, hacemos una conmutación controlada para que una réplica ya actualizada pase a principal y terminamos con el antiguo principal. Así el corte se queda en los segundos de la conmutación. Antes lo ensayamos con una copia y revisamos los cambios de la versión nueva, sobre todo en comandos y en el formato de los archivos de persistencia.
¿Qué pasa con la licencia de Redis?
En 2024 Redis pasó de BSD a RSALv2 y SSPLv1, y de ese cambio nació Valkey, con licencia BSD; con Redis 8 se añadió la opción AGPLv3, que sí es de código abierto. La historia completa y cuándo conviene Valkey están en Valkey gestionado.
Para la mayoría de empresas que usan Redis dentro de su aplicación, cualquiera de las opciones sirve. Lo revisamos con vosotros si vais a ofrecer Redis como servicio a terceros o si vuestra política interna exige licencias aprobadas por la OSI. Elegimos con criterios prácticos: qué ofrece vuestro proveedor gestionado, qué módulos necesitáis y qué versión soportan vuestras bibliotecas cliente.
¿Cómo migramos de un servicio gestionado a vuestra cuenta, o al revés?
Partimos de una copia RDB exportada o copiamos las claves en vivo con una herramienta de migración, según el tamaño y lo que tolere la aplicación. Para una caché, muchas veces basta con apuntar la aplicación a la instancia nueva y dejar que se llene sola. Para colas y sesiones planificamos el corte en un momento tranquilo. Las métricas acaban en la monitorización con Grafana y Prometheus, y si Redis acompaña a una base de datos relacional, la gestionamos con el mismo enfoque que el PostgreSQL gestionado.
¿Y Memcached?
Memcached es solo una caché en memoria: no guarda nada en disco, no tiene réplica y el reparto entre nodos lo hace la propia aplicación. Para cachear páginas o resultados de consultas es sencillo y rápido, y si vuestra aplicación ya lo usa no hace falta cambiarlo. Lo dimensionamos por memoria, vigilamos la tasa de aciertos y las expulsiones, y no lo tratamos como almacenamiento: si se reinicia, se vacía. Cuando necesitáis que los datos sobrevivan a un reinicio, colas o estructuras como listas y conjuntos, os recomendamos Redis o Valkey. AWS y Google Cloud lo ofrecen gestionado; en el resto lo montamos nosotros.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud con Redis o Valkey, Sentinel en tres máquinas y red privada. Copias RDB a Object Storage de Hetzner, compatible con S3. | Hetzner no ofrece caché gestionada: la réplica, la conmutación y las copias las montamos nosotros. |
| AWS | ElastiCache para Valkey o Redis OSS, o MemoryDB cuando Redis es la base de datos principal y no basta con una caché. | Revisamos tamaño de nodo, política de expulsión, réplicas entre zonas y que la copia se restaura. |
| Google Cloud | Memorystore for Valkey o Memorystore for Redis, con modo clúster si hace falta repartir datos. | Acceso privado desde vuestra VPC; nada expuesto a internet. |
| Azure | Azure Managed Redis, que sustituye a Azure Cache for Redis, o máquinas virtuales con Valkey y Sentinel. | Si ya usáis Azure Cache for Redis, planificamos la migración que Microsoft indica antes de la retirada. |
| DigitalOcean | Managed Caching for Valkey, que ha sustituido a su antiguo Redis gestionado, o Droplets con Sentinel. | |
| OVH | Valkey gestionado de OVHcloud Public Cloud, o instancias con Valkey y Sentinel montados por nosotros. | |
| Servidor propio | Redis o Valkey en vuestros servidores o máquinas virtuales, con Sentinel y copias RDB a un almacenamiento S3 externo. | Tres máquinas para Sentinel; con dos, una caída de red puede dejar dos principales a la vez. |
Qué incluye
- Redis o Valkey en vuestra cuenta cloud o en vuestros servidores, o el servicio gestionado de vuestro proveedor si encaja mejor.
- Persistencia elegida según el uso: sin persistencia para caché pura, RDB, AOF o ambas para colas y sesiones.
- Réplica y conmutación automática con Sentinel, o Redis Cluster cuando los datos no caben en un nodo.
- maxmemory y política de expulsión ajustadas a cada instancia, separando caché de datos que no se pueden perder.
- Usuarios con ACL por aplicación, TLS y acceso solo desde la red privada.
- Métricas con redis_exporter y alertas de memoria, expulsiones, conexiones rechazadas y réplica retrasada.
- Copias RDB fuera del servidor y restauración de prueba con el tiempo medido.
- Actualizaciones ensayadas, réplica a réplica, y la configuración en Terraform o Ansible en vuestro repositorio.
Preguntas frecuentes
¿Elegimos Redis o Valkey?
Para caché, colas y sesiones los dos funcionan igual: Valkey nació de Redis 7.2.4 y habla el mismo protocolo, así que las bibliotecas cliente sirven. Valkey tiene licencia BSD y lo mantiene la Linux Foundation. Redis 8 se puede usar bajo AGPLv3, que es código abierto, o bajo RSALv2 o SSPLv1. Si vuestro proveedor ofrece uno de los dos gestionado, solemos partir de ese.
¿Podemos perder datos si Redis se reinicia?
Depende de la persistencia. Sin ella, se pierde todo, lo cual está bien para una caché. Con RDB perdéis lo escrito desde la última instantánea; con AOF y escritura a disco cada segundo, como mucho un segundo. Para colas y sesiones configuramos AOF y dejamos escrito cuánto se puede perder.
¿Sentinel o Redis Cluster?
Sentinel cuando los datos caben en la memoria de un servidor: un principal, réplicas y conmutación automática. Cluster cuando no caben o cuando las escrituras no las aguanta un solo nodo. Cluster reparte las claves y obliga a que las operaciones con varias claves estén en el mismo slot, así que la aplicación tiene que estar preparada.
¿Lo montáis dentro de Kubernetes?
Sí, con un operador o un StatefulSet, volúmenes persistentes y reglas para que las réplicas no caigan en el mismo nodo. Si la caché es crítica y el proveedor tiene servicio gestionado, muchas veces os recomendamos sacarla del clúster.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el