Saltar al contenido

Redis — el cuchillo suizo en memoria.

Redis es una base de datos que vive en RAM. Cero tablas, cero JOINs. Todo son claves que apuntan a valores, pero el valor puede ser una de cinco estructuras muy poderosas. Es rapidísima — milisegundos — y por eso se usa para sesiones, carritos, cachés, colas y rankings.

01Las cinco estructuras

Toda la magia se reduce a esto: una clave (string), un valor (5 sabores posibles).

"abc"
STRING
El más simple. Texto, número o blob. Si parece número, soporta INCR.
↦↦
LIST
Cola/pila ordenada de strings. Empujas por la izquierda o por la derecha.
{k:v}
HASH
Como un objeto JSON pequeño dentro de una clave: campos → valores.
{•}
SET
Bolsa de strings sin duplicados, sin orden.
↧#
ZSET
Como un SET pero cada miembro lleva un score. Mantiene orden — ideal para rankings.

02Sintaxis del CLI

Redis no usa SQL. Le hablas con comandos cortos en mayúsculas, separados por espacios:

SET nombre "Ana"
GET nombre
INCR contador
LPUSH cola "tarea1" "tarea2"
HSET usuario:1 nombre "Ana" edad 30

Lo verás aún más claro abajo — el lab te deja escribir comandos reales y ver cómo aparecen las claves al instante.

03Tu primer lab Redis

~/redis-labredis · in-memory
redis-cli
# Una STRING simple
SET nombre "Ana"
GET nombre

# Un contador (también es STRING, pero numérico)
SET visitas 0
INCR visitas
INCR visitas
INCR visitas
listo
La base está vacía. Escribe un SET clave valor y ejecuta.
Convención de nombres

Las claves suelen llevar namespaces con dos puntos: usuario:1, cart:42, post:7:likes. No es obligatorio, pero hace mucho más fácil agrupar y debuggear.

04Caso 1 · HASH Carrito de compras

Un carrito necesita dos cosas: qué productos y cuánta cantidad de cada uno. Eso es literalmente un HASH: cart:userId donde cada field es un producto y el value es la cantidad.

Toca la tienda de la izquierda y mira cómo se construye el HASH en Redis. Cada botón emite el comando que aparece abajo a la derecha.

Tienda online · carrito de Ana
HASH · cart:ana
Catálogo
Carrito0
Café Sierra Nevada
$ 32.000
Té verde japonés
$ 12.000
Galletas integral
$ 6.000
Chocolate amargo
$ 22.000
Tu carrito
Carrito vacío. Agrega algo del catálogo de arriba.
Estado en Redis
emptycart:ana
(la clave no existe — un carrito vacío sencillamente no se guarda)
Últimos comandos
Aún no hay comandos. Interactúa a la izquierda →
Por qué un HASH y no varias keys

Podrías usar SET cart:1:sku-42 1, SET cart:1:sku-99 2... pero entonces "ver el carrito completo" necesitaría escanear todas las claves (lento). Con HASH, una sola lectura (HGETALL) trae todo.

05Caso 2 · STRING + TTL Sesión de usuario

Cuando alguien inicia sesión, el servidor genera un token y necesita guardar "a qué usuario pertenece este token, y por cuánto tiempo es válido". Redis es perfecto: clave única + valor + TTL que el motor mismo gestiona.

El truco es el modificador EX seconds al final del SET — la clave se autodestruye. Prueba el flujo en el lab: crea la sesión con TTL, luego consulta cuánto tiempo le queda.

~/redis-labredis · in-memory
redis-cli
# Crear sesión con TTL de 30 segundos
SET session:tok_abc123 "user:ana" EX 30
TTL session:tok_abc123

# Ver el valor
GET session:tok_abc123

# Expirar manualmente
DEL session:tok_abc123
GET session:tok_abc123
listo
La base está vacía. Escribe un SET clave valor y ejecuta.
Atención con el TTL

El TTL aplica a la clave entera, no a campos individuales. Si necesitas que un campo de un HASH expire por separado, conviene usar claves distintas con su propio TTL.

06Caso 3 · INCR Botón de like

Un post que recibe 10.000 likes por segundo es un nightmare para una base relacional: cada UPDATE bloquea filas, los índices se actualizan, hay locks... Redis lo hace en microsegundos porque INCR es atómico y no toca disco.

En el lab de abajo, combinamos un HASH para los contadores y un SET para registrar qué usuarios ya dieron like — así evitamos el like-spam sin lógica extra en el servidor.

~/redis-labredis · in-memory
redis-cli
# Inicializar contadores del post
HSET post:42:stats likes 0 views 1

# Simular likes de distintos usuarios
SADD post:42:liked_by "ana"
HINCRBY post:42:stats likes 1

SADD post:42:liked_by "luis"
HINCRBY post:42:stats likes 1

# Ver estado completo
HGETALL post:42:stats
SMEMBERS post:42:liked_by
listo
La base está vacía. Escribe un SET clave valor y ejecuta.
Atomicidad

INCR es atómico: si mil clientes hacen INCR al mismo tiempo, el número final es exactamente mil más. No hay race conditions. Esa propiedad es la que vuelve a Redis ideal para contadores, rate-limiting, locks y semáforos.

07Cuándo Redis, cuándo NO Redis

Sí, Redis
Sesiones, carritos efímeros, contadores, leaderboards, caches de consultas, colas de tareas, rate limiting, pub/sub en tiempo real.
No, Redis
Datos críticos donde no puedes permitir perder nada al reiniciar (aunque hay persistencia, no es su fuerte). Reportes con queries arbitrarias. Joins complejos. Búsqueda full-text (mejor Elasticsearch).
Resumen

Redis no reemplaza a una base relacional — la acompaña. Postgres guarda la verdad, Redis guarda lo rápido. La inmensa mayoría de apps grandes usan ambas.