Azure Managed Redis: bibliotecas, caché y operaciones de datos

radio_button_uncheckedshort_text1. Por qué una aplicación de IA necesita una estrategia de caché

Piensa en un asistente de comercio electrónico que combina perfil, catálogo, historial de conversación, sesión y resultados costosos de modelos durante miles de chats simultáneos. Consultar el sistema de registro en cada turno aumenta latencia y carga. Azure Managed Redis mantiene los datos reutilizados en memoria para responder en tiempo de caché inferior a un milisegundo, mientras la base duradera sigue siendo la fuente de verdad.

• Explicar el servicio administrado, sus niveles y los patrones comunes de caché.
• Elegir una biblioteca y un modo de conexión compatibles con la directiva de clustering.
• Almacenar, recuperar, agrupar, expirar y eliminar datos con redis-py.
• Aplicar cache-aside, invalidación explícita, pooling, reintentos, seguridad, supervisión y recuperación.
• Crear y comprobar una aplicación de consola Python contra un recurso desechable.

Resumen del tema

Usa Redis para datos limitados, repetibles y sensibles a latencia, y conserva propiedad y durabilidad en el sistema de origen.

radio_button_uncheckedshort_text2. Comprender la arquitectura administrada de Redis

Azure Managed Redis es un almacén en memoria operado por Microsoft y hospedado en Azure sobre Redis Enterprise. Conserva el protocolo Redis y agrega implementación administrada, particiones paralelas, alta disponibilidad, replicación geográfica activa-activa, controles de seguridad y supervisión de Azure. Las aplicaciones dentro o fuera de Azure pueden conectarse cuando la red lo permita.

Varios procesos de servidor Redis, o shards, se distribuyen entre nodos. Los shards principales y las réplicas ocupan nodos distintos, y un proxy por nodo administra conexiones y autorreparación. Parte de la memoria se reserva para replicación y conmutación por error; dimensiona por capacidad útil medida y no por todo el tamaño anunciado.

La replicación geográfica activa-activa enlaza instancias de varias regiones. Todas aceptan lecturas y escrituras y los cambios convergen con coherencia eventual. La aplicación aún debe dirigir tráfico a una región sana y no asumir sincronización inmediata entre regiones.

Resumen del tema

El servicio combina acceso compatible con Redis, shards, réplicas, proxies, conmutación y operación activa-activa multirregional opcional.

radio_button_uncheckedshort_text3. Elegir el patrón de caché según el ciclo de vida

En cache-aside, la aplicación consulta Redis primero. Un acierto vuelve de inmediato; un error lee la base, guarda una representación reutilizable con expiración y devuelve el resultado. Como la base suele ser mayor que la caché, cargar bajo demanda es más práctico que precargar todo. Cuando cambia el origen, elimina o reemplaza cada clave derivada que pueda quedar obsoleta.

Los fragmentos estáticos reducen renderizado y servidores web. ASP.NET puede usar Redis Output Cache Provider y otros marcos aplican la misma idea mediante sus abstracciones de caché. El clustering distribuye conjuntos grandes de contenido.

Para las sesiones, deja en la cookie solo un identificador opaco y guarda el estado mayor en Redis. Así no se transmite toda la sesión en cada solicitud y respuesta HTTP. Hay integración con ASP.NET, ASP.NET Core, Node.js, Python y Java; replicación y expiración ayudan a la disponibilidad y limpieza.

Resumen del tema

Datos, contenido y sesiones tienen propietarios y caducidades distintas, pero se benefician cuando valores pequeños evitan trabajo repetido.

radio_button_uncheckedshort_text4. Seleccionar el nivel con evidencias de memoria y rendimiento

El nivel fija techo de rendimiento, memoria útil, disponibilidad y coste mensual. Prueba tamaños reales, mezcla de comandos, concurrencia, red y alta disponibilidad. En esta edición, Flash Optimized y algunos SKU en memoria de gran tamaño están en versión preliminar; comprueba disponibilidad y límites actuales en la región.

La directiva de expulsión decide qué sale al llenarse la memoria, pero no reemplaza la planificación. TTL, tamaño máximo, número de claves, sobrecarga de replicación y margen seguro deben incluirse.

Resumen del tema

Elige el nivel con memoria y rendimiento medidos y valida región, versión preliminar, expulsión y coste.

radio_button_uncheckedshort_text5. Relacionar biblioteca, lenguaje y directiva de clustering

Las bibliotecas convierten sus API en comandos Redis y las mantienen sus comunidades, no el equipo del servicio. Usa una versión actual y mantenida y revisa actualizaciones porque la conexión, el soporte de clúster, la confiabilidad y el rendimiento evolucionan.

Todo cliente funciona con clustering Enterprise porque el proxy expone un endpoint compatible. Con OSS, el cliente debe entender topología y ranuras de Redis Cluster. En Python usa redis.cluster.RedisCluster, no redis.Redis. Es una decisión de conexión, no un detalle posterior.

Resumen del tema

Elige un cliente comunitario actual y confirma que su clase de conexión admite la directiva de clustering.

radio_button_uncheckedshort_text6. Diseñar comandos de varias claves para ranuras y restricciones

Un clúster divide claves entre ranuras hash. Con OSS, todas las claves de un comando múltiple deben ocupar la misma ranura o aparece CROSSSLOT. Una etiqueta compartida, como user:{42}:profile y user:{42}:cart, agrupa claves relacionadas, pero demasiado tráfico concentrado crea un shard caliente.

Como Microsoft controla la topología, Enterprise bloquea CLUSTER INFO, CLUSTER HELP, CLUSTER KEYSLOT, CLUSTER NODES y CLUSTER SLOTS. La replicación geográfica activa bloquea FLUSHALL y FLUSHDB. El código no debe depender de comandos administrativos que pertenecen a la plataforma.

Resumen del tema

La ranura determina el comportamiento multiclave y las restricciones administradas protegen topología y datos replicados.

radio_button_uncheckedshort_text7. Aplicar buenas prácticas antes de escalar

• Prefiere más claves con valores pequeños y divide objetos grandes.
• Usa canalización para reducir viajes de red entre operaciones independientes.
• Itera con SCAN; KEYS puede bloquear el servidor y no debe usarse en producción.
• Coloca la aplicación y Redis en la misma región de Azure cuando sea posible.
• Conecta por nombre de host, no por una IP pública que puede cambiar.
• Mantén TLS; el servicio admite TLS 1.2 y 1.3 y exige transporte cifrado de forma predeterminada.
• Para demanda excepcional de ancho de banda, prueba un cliente mayor o varias conexiones round-robin.

La canalización reduce viajes, pero no es una transacción: la atomicidad depende del comando o de una transacción explícita. Mide latencia y carga para no mover el cuello a la red cliente.

Resumen del tema

Valores pequeños, canalización, iteración no bloqueante, proximidad, hostnames y TLS suelen ayudar antes de aumentar capacidad.

radio_button_uncheckedshort_text8. Conectar con redis-py y Microsoft Entra ID

Azure Managed Redis y cachés Enterprise usan el puerto TLS 10000; Azure Cache for Redis usa 6380. Confundirlos causa errores. decode_responses=True convierte bytes en texto; déjalo false para imágenes, objetos serializados o datos binarios.

import redis

# Access-key example; prefer Microsoft Entra ID in production
client = redis.Redis(
    host="<cache-name>.<region>.redis.azure.net",
    port=10000,
    ssl=True,
    password="<access-key>",
    decode_responses=True,
)

# Use decode_responses=False for images or other binary payloads.

Las claves de acceso funcionan, pero Microsoft Entra ID es el modelo sin contraseña preferido en producción. Los nuevos cachés lo habilitan de forma predeterminada. Concede al usuario, entidad de servicio o identidad administrada solo los permisos necesarios y deja que el proveedor actualice tokens.

import redis
from azure.identity import DefaultAzureCredential
from redis_entraid.cred_provider import create_from_default_azure_credential

provider = create_from_default_azure_credential(
    ("https://redis.azure.com/.default",),
)

client = redis.Redis(
    host="<cache-name>.<region>.redis.azure.net",
    port=10000,
    ssl=True,
    credential_provider=provider,
    decode_responses=True,
)

# With OSS clustering, use redis.cluster.RedisCluster instead.

Microsoft Entra requiere TLS y usa el ámbito https://redis.azure.com/.default. Deshabilitar claves de acceso termina todas las conexiones actuales; planifica transición y reconexión.

Resumen del tema

Usa puerto TLS y cliente de clúster correctos, prefiere Microsoft Entra ID y trata renovación y reconexión como operaciones normales.

radio_button_uncheckedshort_text9. Elegir la estructura Redis según la operación

Los hashes agrupan campos bajo una clave y suelen usar menos memoria que una clave por campo. Las listas conservan orden y trabajan en ambos extremos. Los comandos numéricos son atómicos y evitan la carrera de leer, incrementar y escribir por separado.

# Strings and batches
client.set("profile:42:name", "Ada")
name = client.get("profile:42:name")
client.mset({"feature:a": "on", "feature:b": "off"})
flags = client.mget("feature:a", "feature:b")

# Hashes model structured objects
client.hset("profile:42", mapping={"name": "Ada", "plan": "pro"})
profile = client.hgetall("profile:42")

# Lists implement queues or recent-item feeds
client.rpush("jobs:pending", "job-1001")
job = client.lpop("jobs:pending")

# Atomic numeric counters avoid read-modify-write races
count = client.incr("rate:user:42")

Resumen del tema

Strings, hashes, listas y contadores resuelven patrones distintos; elige antes de diseñar claves y TTL.

radio_button_uncheckedshort_text10. Almacenar, recuperar, agrupar, comprobar y eliminar

SET y GET forman el par básico. HSET escribe un mapa y HGET o HGETALL lee un campo o todo el objeto. MSET y MGET reducen viajes entre varias strings cuando el clúster lo permite. Varios hashes son claves separadas; usa una canalización para varios HGETALL o HGET.

pipe = client.pipeline()
pipe.hgetall("profile:42")
pipe.hgetall("profile:84")
profiles = pipe.execute()

existing = client.exists("profile:42", "profile:84", "profile:999")
removed = client.delete("profile:42", "session:expired")

EXISTS funciona con todo tipo porque comprueba claves; con varias devuelve cuántas existen. DEL elimina claves completas y devuelve la cantidad. Una clave ausente es un error normal de caché, no un fallo de aplicación.

Resumen del tema

Agrupa operaciones independientes e interpreta las cuentas devueltas por EXISTS y DEL.

radio_button_uncheckedshort_text11. Controlar la expiración con TTL en la clave

La expiración sostiene invalidación automática y memoria. SETEX escribe una string y su caducidad atómicamente; PSETEX usa milisegundos. Para hash, lista o string existente, escribe y aplica EXPIRE o PEXPIRE. EXPIREAT recibe una hora Unix absoluta.

import time

# Atomic write plus expiration for a string
client.setex("session:f7c9", 3600, "user-42")
client.psetex("lock:job-1001", 5000, "worker-3")

# Any data type can receive a key-level expiration
client.expire("profile:42", 900)
client.pexpire("jobs:pending", 60_000)
client.expireat("catalog:snapshot", int(time.time()) + 7200)

ttl = client.ttl("profile:42")   # -1: no expiry; -2: key absent
ttl_ms = client.pttl("profile:42")
client.persist("profile:42")     # remove the expiry

TTL devuelve segundos y PTTL milisegundos. -1 significa que la clave existe sin expiración; -2 que no existe. PERSIST elimina la expiración. Como inicio, usa 1–5 minutos para datos frecuentes, 15–60 para cambio moderado, 1–24 horas para estables y más de un día para referencias estáticas.

Resumen del tema

La caducidad pertenece a la clave, SETEX es atómico y el TTL equilibra frescura, aciertos y memoria.

radio_button_uncheckedshort_text12. Invalidar entradas obsoletas deliberadamente

TTL es sencillo, pero puede servir datos cambiados antes del plazo. La invalidación manual elimina o actualiza las claves relacionadas después de escribir con éxito en la base. Cache-aside combina carga bajo demanda y TTL; la limpieza por patrón usa SCAN sin bloquear.

def get_product(product_id: str, ttl: int = 600):
    key = f"product:{product_id}"
    cached = client.get(key)
    if cached is not None:
        return cached

    value = read_product_from_database(product_id)
    if value is not None:
        client.setex(key, ttl, value)
    return value

def update_product(product_id: str, value: str):
    write_product_to_database(product_id, value)
    client.delete(
        f"product:{product_id}",
        f"recommendations:{product_id}",
    )

def invalidate_user(user_id: str):
    # SCAN advances incrementally; KEYS can block production workloads.
    for key in client.scan_iter(match=f"user:{user_id}:*", count=100):
        client.delete(key)

Escribe primero en la base e invalida después para impedir que una falta de caché recargue el origen antiguo. Para dominios de mucha escritura o coherencia estricta, considera claves versionadas, eventos o write-through. Evita comodines ilimitados; un índice inverso o conjunto pequeño de claves es más operable.

Resumen del tema

TTL limita obsolescencia, invalidar tras actualizar la reduce y SCAN limpia patrones sin el riesgo productivo de KEYS.

radio_button_uncheckedshort_text13. Limitar conexiones, fallos y reintentos

redis-py usa pooling automáticamente. Configura un máximo adecuado, reutiliza clientes y evita abrir TCP/TLS por solicitud. Varios pools pueden repartir demanda excepcional, pero más conexiones no corrigen un servidor saturado.

import random
import time
import redis

pool = redis.ConnectionPool(
    connection_class=redis.SSLConnection,
    host="<cache-name>.<region>.redis.azure.net",
    port=10000,
    max_connections=40,
    socket_connect_timeout=2,
    socket_timeout=2,
    health_check_interval=30,
    decode_responses=True,
)
client = redis.Redis(connection_pool=pool)

for attempt in range(3):
    try:
        value = client.get("model:result:42")
        break
    except (redis.ConnectionError, redis.TimeoutError):
        if attempt == 2:
            raise
        time.sleep((2 ** attempt) * 0.1 + random.random() * 0.1)

Define timeouts breves, captura errores y permite recurrir a la fuente de verdad o responder de forma degradada. Reintenta solo trabajo transitorio e idempotente con backoff exponencial y jitter. No repitas a ciegas una escritura cuyo resultado sea desconocido.

Resumen del tema

Pool limitado, timeouts, degradación controlada y pocos reintentos con jitter aíslan una incidencia de caché.

radio_button_uncheckedshort_text14. Supervisar, escalar y proteger la caché

Supervisa Porcentaje de memoria usada, CPU, Clientes conectados, ancho de banda, latencia, timeouts, expulsiones y relación acierto/error. El material propone investigar uso sostenido por encima de aproximadamente 75% en las cuatro métricas de capacidad; las alertas reales deben reflejar línea base, límites y objetivo de respuesta.

• Habilita alta disponibilidad en producción; desactívala solo en desarrollo o prueba cuando el riesgo sea aceptable.
• Usa replicación geográfica activa-activa entre regiones, diseñando coherencia eventual y conmutación de tráfico en la aplicación.
• Usa persistencia RDB o AOF para recuperar más rápido el mismo caché; no es copia de seguridad puntual.
• Usa importación/exportación para copias en una cuenta de almacenamiento y confirma incompatibilidades actuales con replicación activa.
• Escala después de identificar si el límite es memoria, CPU, red, conexiones o tamaño del valor.

Resumen del tema

Métricas, aciertos, latencia, disponibilidad, persistencia, copias y replicación forman un solo diseño operativo.

radio_button_uncheckedshort_text15. Laboratorio guiado: realizar operaciones desde Python

El ejercicio de origen dura unos 30 minutos. Usa un recurso desechable y registra los resultados de cada comando.

1. Prepara una suscripción de Azure, Visual Studio Code, Python 3.12 o posterior, la última CLI de Azure y la extensión redisenterprise instalada con az extension add --name redisenterprise.
2. Crea un proyecto de consola e instala redis, redis-entraid y azure-identity según la autenticación.
3. Crea Azure Managed Redis, obtén hostname y clustering y concede acceso a la identidad ejecutora.
4. Conecta por TLS 10000 y comprueba PING.
5. Guarda un perfil como hash, lee campos y agrupa dos lecturas con canalización.
6. Aplica expiración, inspecciona TTL, quítala y reaplica; elimina la clave y confirma TTL -2.
7. Implementa cache-aside e invalidación, desconecta, elimina el recurso y conserva solo notas sin secretos.

Resumen del tema

El laboratorio prueba aprovisionamiento, conexión segura, hashes, canalización, TTL, eliminación y limpieza en Python.

radio_button_uncheckedshort_text16. Revisión de evaluación y lista de producción

1. El puerto cifrado predeterminado de Azure Managed Redis es 10000; 6380 corresponde a Azure Cache for Redis.
2. Usa SCAN en lugar de KEYS para iterar claves en producción.
3. setex() de redis-py guarda una string y su expiración atómicamente.
4. TTL -1 indica una clave sin caducidad; TTL -2, una clave ausente.
5. Enterprise y OSS tienen requisitos diferentes para conexión y varias claves.
6. Microsoft Entra ID con TLS es la autenticación de producción preferida.

• Normaliza claves y limita valores.
• Elige estructuras según la operación.
• Define TTL o documenta por qué persiste.
• Invalida derivados tras actualizar el origen.
• Usa canalización, pool limitado, timeout y reintento idempotente.
• Supervisa memoria, CPU, clientes, red, latencia, expulsiones y aciertos.
• Prueba alta disponibilidad y recuperación y elimina recursos de laboratorio.

Referencias oficiales

1. ¿Qué es Azure Managed Redis?
2. Arquitectura de Azure Managed Redis
3. Procedimientos recomendados para bibliotecas cliente
4. Procedimientos recomendados de desarrollo
5. Autenticación de caché con Microsoft Entra ID
6. Crear una aplicación Python con Azure Managed Redis
7. Guía de almacenamiento en caché de Azure Architecture Center

Resumen del tema

Una caché de producción une comandos correctos, conciencia del clúster, identidad segura, frescura acotada, capacidad observable y fallos probados.