Redis Gerenciado pelo Azure: bibliotecas, cache e operações de dados

radio_button_uncheckedshort_text1. Por que uma aplicação de IA precisa de uma estratégia de cache

Considere um assistente de comércio eletrônico que reúne perfil do cliente, catálogo, histórico de conversa, estado de sessão e resultados caros de modelos em milhares de chats simultâneos. Consultar o sistema de registro em cada turno aumenta latência e carga. O Redis Gerenciado pelo Azure mantém dados reutilizados na memória para atender o caminho quente em tempo de cache inferior a um milissegundo, enquanto o banco durável permanece como fonte da verdade.

• Explicar o serviço gerenciado, suas camadas e estratégias comuns de cache.
• Escolher uma biblioteca e um modo de conexão compatível com a política de clustering.
• Armazenar, recuperar, agrupar, expirar e remover dados com redis-py.
• Aplicar cache-aside, invalidação explícita, pooling, repetição, segurança, monitoramento e recuperação.
• Criar e verificar um pequeno aplicativo de console Python em um recurso descartável.

Resumo do tópico

Use Redis para dados limitados, repetíveis e sensíveis à latência, mantendo propriedade e durabilidade no sistema de origem adequado.

radio_button_uncheckedshort_text2. Entender a arquitetura gerenciada do Redis

O Redis Gerenciado pelo Azure é um armazenamento em memória operado pela Microsoft e hospedado no Azure, baseado no Redis Enterprise. Ele preserva o protocolo Redis e acrescenta implantação gerenciada, shards paralelos, alta disponibilidade, replicação geográfica ativa-ativa, controles de segurança e monitoramento do Azure. Aplicações dentro ou fora do Azure podem se conectar quando a rede permitir.

Vários processos de servidor Redis, chamados shards, são distribuídos entre nós. Shards primários e réplicas ocupam nós diferentes, e um proxy em cada nó gerencia conexões e autorrecuperação. Parte da memória fica reservada para replicação e failover; portanto, dimensione pela capacidade utilizável medida, não pelo tamanho nominal inteiro.

A replicação geográfica ativa-ativa vincula instâncias em regiões diferentes. Todas podem aceitar leituras e gravações, e as alterações convergem com consistência eventual. A aplicação ainda deve direcionar tráfego para uma região saudável e não pode presumir sincronização inter-regional imediata.

Resumo do tópico

O serviço combina acesso compatível com Redis, shards, réplicas, proxies, failover e operação ativa-ativa multirregional opcional.

radio_button_uncheckedshort_text3. Escolher o padrão de cache pelo ciclo de vida dos dados

No cache-aside, a aplicação consulta Redis primeiro. Um acerto retorna imediatamente; uma falha lê o banco, grava uma representação reutilizável com expiração e devolve o resultado. Como o banco costuma ser maior que o cache, carregar sob demanda é mais realista que pré-carregar tudo. Quando a origem muda, remova ou substitua cada chave derivada que possa estar obsoleta.

Fragmentos estáticos reduzem renderização e o número de servidores Web exigido. ASP.NET pode usar o Redis Output Cache Provider, e outros frameworks aplicam o mesmo padrão por suas abstrações de cache. O clustering distribui grandes conjuntos de conteúdo.

Para sessões, mantenha no cookie apenas um identificador opaco e guarde o estado maior no Redis. Assim, o cliente não transmite a sessão completa em toda solicitação e resposta HTTP. Há integração para ASP.NET, ASP.NET Core, Node.js, Python e Java; replicação e expiração apoiam disponibilidade e limpeza.

Resumo do tópico

Dados, conteúdo compartilhado e sessões têm proprietários e expirações diferentes, mas todos ganham quando valores pequenos evitam trabalho repetido.

radio_button_uncheckedshort_text4. Selecionar a camada com evidências de memória e taxa de transferência

A camada define teto de desempenho, memória utilizável, recursos de disponibilidade e custo mensal. Teste tamanho real dos valores, mistura de comandos, concorrência, rede e alta disponibilidade. Nesta edição, Flash Optimized e alguns SKUs em memória muito grandes estão em versão prévia; confirme disponibilidade e limites atuais na região.

A política de remoção decide o que sai quando a memória enche, mas não substitui planejamento. TTL, tamanho máximo, número de chaves, custo de replicação e margem segura precisam entrar no cálculo.

Resumo do tópico

Escolha a camada por memória e taxa medidas e valide disponibilidade, status de versão prévia, remoção e custo na região.

radio_button_uncheckedshort_text5. Relacionar biblioteca, linguagem e política de clustering

As bibliotecas convertem APIs em comandos Redis e são mantidas por suas comunidades, não pela equipe do serviço. Use uma versão atual e com manutenção ativa; revisite atualizações regularmente porque suporte a cluster, conexão, confiabilidade e desempenho evoluem.

Todo cliente funciona com a política de clustering Enterprise, pois o proxy apresenta um endpoint compatível. Na política OSS, o cliente precisa compreender topologia e slots do Redis Cluster. Em Python, use redis.cluster.RedisCluster em vez de redis.Redis. Essa é uma decisão de conexão, não um detalhe tardio.

Resumo do tópico

Escolha um cliente comunitário atual e confirme que a classe de conexão aceita a política de clustering da instância.

radio_button_uncheckedshort_text6. Projetar comandos de várias chaves para slots e restrições

Um cache em cluster divide as chaves em slots de hash. Na política OSS, todas as chaves de um comando múltiplo precisam cair no mesmo slot, ou ocorre CROSSSLOT. Uma tag compartilhada, como user:{42}:profile e user:{42}:cart, agrupa dados relacionados, mas concentrar tráfego demais cria um shard quente.

Como a Microsoft controla a topologia, o clustering Enterprise bloqueia CLUSTER INFO, CLUSTER HELP, CLUSTER KEYSLOT, CLUSTER NODES e CLUSTER SLOTS. A replicação geográfica ativa bloqueia FLUSHALL e FLUSHDB. O código da aplicação não deve depender de comandos administrativos pertencentes à plataforma.

Resumo do tópico

A posição no slot governa operações de várias chaves, e as restrições do serviço protegem topologia e dados replicados.

radio_button_uncheckedshort_text7. Aplicar práticas de desenvolvimento antes de aumentar capacidade

• Prefira mais chaves com valores menores e divida objetos grandes.
• Use pipeline para reduzir viagens de rede entre operações independentes.
• Itere com SCAN; KEYS pode bloquear o servidor e não deve fazer parte do caminho de produção.
• Coloque aplicação e Redis na mesma região do Azure quando possível.
• Conecte por nome do host, nunca por IP público sujeito a mudança.
• Mantenha TLS; o serviço aceita TLS 1.2 e 1.3 e exige transporte criptografado por padrão.
• Para demanda excepcional de banda, teste um cliente maior ou várias conexões em round-robin.

Pipeline reduz viagens, mas não é sinônimo de transação; atomicidade vem do comando ou de uma transação explícita. Meça latência dos comandos e carga do servidor para não deslocar o gargalo para a rede do cliente.

Resumo do tópico

Valores pequenos, pipeline, iteração não bloqueante, proximidade regional, hostnames e TLS costumam ajudar antes da escala.

radio_button_uncheckedshort_text8. Conectar com redis-py e Microsoft Entra ID

Redis Gerenciado pelo Azure e caches Enterprise usam a porta TLS 10000; Cache do Azure para Redis usa 6380. Trocar esses padrões é uma causa comum de falha. decode_responses=True converte bytes em texto; mantenha false para imagens, objetos serializados ou dados binários.

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.

Chaves de acesso funcionam, mas Microsoft Entra ID é o modelo sem senha preferido em produção. Novos caches habilitam essa autenticação por padrão. Conceda ao usuário, entidade de serviço ou identidade gerenciada somente as permissões necessárias e deixe o provedor atualizar 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.

A autenticação Microsoft Entra exige TLS e usa o escopo https://redis.azure.com/.default. Desabilitar chaves de acesso encerra todas as conexões atuais; planeje a transição e a reconexão.

Resumo do tópico

Use porta TLS e cliente de cluster corretos, prefira Microsoft Entra ID e trate renovação e reconexão como comportamento normal.

radio_button_uncheckedshort_text9. Escolher a estrutura Redis conforme a operação

Hashes agrupam campos sob uma chave e normalmente usam menos memória que uma chave por campo. Lists preservam ordem e operam nas duas extremidades. Comandos numéricos são atômicos e evitam a corrida de ler, incrementar e gravar separadamente.

# 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")

Resumo do tópico

Strings, hashes, lists e contadores atômicos resolvem padrões distintos; escolha antes de definir chaves e TTLs.

radio_button_uncheckedshort_text10. Armazenar, recuperar, agrupar, verificar e excluir

SET e GET formam o par básico. HSET grava um mapeamento e HGET ou HGETALL lê um campo ou o objeto. MSET e MGET reduzem viagens entre várias strings quando o cluster permite. Vários hashes são chaves separadas; use pipeline para executar diversos HGETALL ou HGET com eficiência.

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 com todos os tipos porque verifica chaves; com várias, retorna quantas existem. DEL remove chaves inteiras e devolve a quantidade excluída. Uma chave ausente deve ser tratada como falha normal de cache.

Resumo do tópico

Agrupe operações independentes e interprete corretamente as contagens retornadas por EXISTS e DEL.

radio_button_uncheckedshort_text11. Controlar expiração com TTL no nível da chave

Expiração sustenta invalidação automática e uso de memória. SETEX grava uma string e sua expiração atomicamente; PSETEX usa milissegundos. Para hash, list ou string existente, grave e aplique EXPIRE ou PEXPIRE. EXPIREAT recebe um horário Unix absoluto.

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 informa segundos e PTTL milissegundos. -1 significa que a chave existe sem expiração; -2, que ela não existe. PERSIST remove a expiração. Como ponto inicial, use cerca de 1–5 minutos para dados muito mutáveis, 15–60 para mudanças moderadas, 1–24 horas para dados estáveis e mais de um dia para referências estáticas.

Resumo do tópico

A expiração pertence à chave, SETEX é uma gravação atômica de string, e o TTL equilibra atualização, taxa de acerto e memória.

radio_button_uncheckedshort_text12. Invalidar entradas obsoletas deliberadamente

TTL é simples, mas pode servir dados alterados antes do prazo. A invalidação manual remove ou atualiza chaves relacionadas depois de uma gravação bem-sucedida no banco. Cache-aside combina carga sob demanda e TTL; limpeza por padrão usa SCAN para descobrir chaves sem 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)

Grave primeiro no banco e invalide depois, evitando que uma falha de cache recarregue a origem antiga. Para domínios muito mutáveis ou estritos, considere chaves versionadas, eventos ou write-through. Evite curingas ilimitados; um índice reverso ou conjunto pequeno e previsível de chaves é mais fácil de operar.

Resumo do tópico

TTL limita obsolescência, invalidação após atualização a encurta, e SCAN limpa padrões incrementalmente sem o risco de KEYS.

radio_button_uncheckedshort_text13. Limitar conexões, falhas e repetições

redis-py usa pool automaticamente. Configure um limite compatível com a concorrência, reutilize clientes e não abra uma sessão TCP/TLS por solicitação. Vários pools podem distribuir demanda excepcional, mas conexões extras não corrigem saturação do servidor.

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)

Defina timeouts curtos, capture erros de conexão e permita fallback para a fonte da verdade ou resposta degradada controlada. Repita somente trabalho transitório e idempotente, com backoff exponencial e jitter. Não repita cegamente uma gravação de resultado desconhecido.

Resumo do tópico

Pool limitado, timeouts, fallback e poucas repetições com jitter impedem que uma falha de cache derrube toda a aplicação.

radio_button_uncheckedshort_text14. Monitorar, escalar e proteger o cache

Observe Percentual de Memória Usada, CPU, Clientes Conectados, banda de rede, latência, timeouts, remoções e razão entre acertos e falhas. O material sugere investigar uso sustentado acima de cerca de 75% nas quatro métricas de capacidade; alertas reais devem refletir baseline, limites da camada e objetivo de resposta.

• Habilite alta disponibilidade em produção e desabilite apenas em desenvolvimento/teste quando o risco for aceitável.
• Use replicação geográfica ativa-ativa para várias regiões, projetando consistência eventual e failover de tráfego pela aplicação.
• Use persistência RDB ou AOF para recuperação mais rápida no mesmo cache; persistência não é backup pontual.
• Use importação/exportação para cópias em conta de armazenamento e confirme incompatibilidades atuais entre persistência e replicação ativa.
• Escale somente depois de identificar memória, CPU, rede, conexões ou tamanho de valor como restrição.

Resumo do tópico

Métricas, taxa de acerto, latência, disponibilidade, persistência, cópia e replicação formam um único projeto operacional.

radio_button_uncheckedshort_text15. Laboratório guiado: executar operações de dados em Python

O exercício de origem foi planejado para cerca de 30 minutos. Use um recurso descartável e registre os resultados dos comandos.

1. Prepare uma assinatura do Azure, Visual Studio Code, Python 3.12 ou superior, a CLI do Azure mais recente e a extensão redisenterprise instalada com az extension add --name redisenterprise.
2. Crie um projeto de console e instale redis, redis-entraid e azure-identity conforme a autenticação.
3. Crie o Redis Gerenciado pelo Azure, obtenha hostname e política de clustering e conceda acesso à identidade executora.
4. Conecte pela porta TLS 10000 e confirme PING.
5. Grave um perfil como hash, leia campos e agrupe duas leituras com pipeline.
6. Defina expiração, inspecione TTL, remova e reaplique a expiração; exclua a chave e confirme TTL -2.
7. Implemente cache-aside e invalidação explícita, desconecte, remova o recurso e guarde apenas anotações sem segredos.

Resumo do tópico

O laboratório comprova provisionamento, conexão segura, hashes, pipeline, TTL, exclusão e limpeza em um fluxo Python repetível.

radio_button_uncheckedshort_text16. Revisão da avaliação e checklist de produção

1. A porta criptografada padrão do Redis Gerenciado pelo Azure é 10000; 6380 pertence ao Cache do Azure para Redis.
2. Use SCAN, não KEYS, para iterar chaves em produção.
3. setex() do redis-py grava string e expiração numa operação atômica.
4. TTL -1 indica chave sem expiração; TTL -2 indica chave ausente.
5. Clustering Enterprise e OSS exigem comportamentos diferentes para conexão e várias chaves.
6. Microsoft Entra ID com TLS é a autenticação preferida para produção.

• Padronize chaves e limite valores.
• Escolha estruturas pela operação.
• Defina TTL ou documente por que a chave persiste.
• Invalide derivados depois da atualização da origem.
• Use pipeline, pool limitado, timeout e repetição idempotente.
• Monitore memória, CPU, clientes, banda, latência, remoções e acertos.
• Teste alta disponibilidade e recuperação e exclua recursos de laboratório.

Referências oficiais

1. O que é o Redis Gerenciado pelo Azure?
2. Arquitetura do Redis Gerenciado pelo Azure
3. Práticas recomendadas para bibliotecas de cliente
4. Práticas recomendadas de desenvolvimento
5. Autenticação de cache com Microsoft Entra ID
6. Criar um aplicativo Python com Redis Gerenciado pelo Azure
7. Diretrizes de cache do Azure Architecture Center

Resumo do tópico

Um cache pronto para produção une comandos corretos, consciência de cluster, identidade segura, atualização limitada, capacidade observável e falhas testadas.