#Empieza por la información que puedes perder
Redis es un servidor que recibe comandos y mantiene estructuras de datos en memoria. Tu programa Python es un cliente: envía una petición por una conexión de red y recibe una respuesta. Un diccionario Python vive dentro de un proceso; una clave de Redis puede ser leída por varios procesos, incluso escritos en lenguajes diferentes. Cerrar el cliente no destruye la clave.
Que el acceso sea rápido no decide si Redis es el lugar correcto para un dato. Primero pregunta qué pasa si desaparece. El precio que aparece en una ficha puede reconstruirse desde la base de datos del catálogo. Un trabajo aceptado que todavía nadie ha ejecutado necesita una estrategia para no perder la intención. Una sesión perdida puede cerrar la sesión del usuario. Son consecuencias diferentes y merecen configuraciones distintas.
#Fuente de verdad
La fuente de verdad es el sistema cuya información decide el estado correcto cuando dos copias discrepan. Una caché conserva información derivada y reconstruible. Si Redis guarda el único ejemplar de una intención de trabajo, deja de ser una simple caché para ese dato: perderlo puede perder trabajo.
No necesitas meter Redis en todos los proyectos. Una base de datos con índices adecuados suele resolver una primera versión. Introducir una caché añade caducidad, invalidación y nuevos modos de fallo. Se justifica cuando mides consultas repetidas costosas, necesitas estructuras compartidas concretas o una distribución de trabajo que tu diseño actual no resuelve cómodamente.
#Las tres piezas que vas a utilizar
| Pieza | Qué hace | Dónde se ejecuta |
|---|---|---|
redis-server |
Mantiene claves y ejecuta comandos | En un proceso servidor |
redis-cli |
Envía comandos escritos en la terminal | Dentro o fuera del contenedor |
redis-py |
Traduce métodos Python al protocolo de Redis | Dentro de tu aplicación |
El protocolo es el formato que acuerdan cliente y servidor para representar instrucciones y respuestas. No necesitas implementarlo. Sí necesitas saber que cada comando puede implicar un viaje por la red: cien lecturas consecutivas pueden tardar mucho más por las esperas que por el trabajo de Redis.
#Preparar un laboratorio reproducible
Usaremos Redis 8.2.3 y redis-py 8.1.0, combinación ejecutada en esta guía. Son versiones fijadas para reproducir los ejemplos; no son una recomendación de mantener indefinidamente una revisión antigua. Antes de desplegar, actualiza dentro de una rama soportada y repite las pruebas. El recorrido usa comandos asentados y explica sus límites, sin depender de todas las novedades de Redis.
Necesitas Python 3.12 o posterior y Docker funcionando. Docker empaqueta el servidor con sus dependencias; el capítulo sobre contenedores explica imagen, contenedor y proceso si son conceptos nuevos. Este comando crea una instancia independiente:
docker run -d --name redis-practica \
-p 127.0.0.1:6380:6379 \
redis:8.2.3-alpine \
redis-server --save '' --appendonly no
-d deja el servidor en segundo plano. --name permite referirse a él. El puerto 6380 del ordenador llega al 6379 del contenedor. 127.0.0.1 limita esa publicación al propio equipo. La etiqueta alpine identifica una variante pequeña de Linux. --save '' y --appendonly no desactivan la persistencia en este laboratorio inicial: un reinicio pierde los datos y permite observar por qué importa la configuración.
docker exec redis-practica redis-cli PING
docker exec redis-practica redis-cli SET curso:saludo hola
docker exec redis-practica redis-cli GET curso:saludo
docker exec lanza el cliente dentro del contenedor existente, donde encuentra Redis en su puerto normal. Espera PONG, OK y hola. Un error de conexión justo al arrancar puede indicar que el proceso todavía se está preparando; consulta docker logs redis-practica y repite PING.
#Ver la frontera entre cliente y servidor
Abre otra terminal y ejecuta el mismo GET. Recupera hola: no dependía de la primera terminal. Ahora reinicia únicamente esta práctica:
docker restart redis-practica
docker exec redis-practica redis-cli GET curso:saludo
Después de que PING vuelva a responder, el resultado es (nil), una respuesta que significa ausencia. El capítulo de persistencia cambiará deliberadamente este comportamiento. Un volumen sin RDB ni AOF no guarda mágicamente los datos que solo estaban en RAM.
#Qué significa que un comando sea atómico
Redis ejecuta cada comando ordinario sobre las claves sin que otro cliente observe un estado intermedio de ese comando. Por ejemplo, INCR contador lee el número, le suma uno y guarda el resultado como una sola operación. Esto no convierte una secuencia Python GET, cálculo, SET en una operación indivisible: otro cliente puede actuar entre ambos comandos.
Tampoco significa que una respuesta OK ya esté en un disco recuperable o que Redis coordine una escritura simultánea en PostgreSQL. Atomicidad, durabilidad y coordinación entre sistemas responden a preguntas diferentes. Las desarrollaremos con fallos concretos, porque confundirlas produce diseños que funcionan en una demostración y fallan con dos procesos.
#Comprobar que ya puedes razonar el sistema
Imagina que un contador desaparece tras reiniciar. Si solo mide visitas aproximadas, quizá aceptes el reinicio. Si controla un saldo que no puede perderse, no basta con añadir EXPIRE: necesitas decidir dónde está el registro duradero y cómo se recupera. La elección depende del significado del dato, no del nombre del comando.
Al terminar toda la práctica inicial puedes eliminar su contenedor con docker rm -f redis-practica. No lo hagas todavía si vas a continuar: los próximos capítulos usan su puerto 6380. No se necesita publicar Redis en Internet ni compartir credenciales para seguir el recorrido.
La documentación de tipos de Redis permite ampliar el catálogo cuando una estructura resuelva una necesidad concreta. En el siguiente capítulo aprenderás primero a elegir entre las estructuras básicas.