Tair (Redis® OSS-Compatible):Use Tair (Redis OSS-compatible) for AI agent short-term memory

Por que usar o Tair para a camada de memória

A memória de agentes de IA é extremamente sensível à latência. Pela Lei de Little, concorrência ≈ QPS × latência. Quando a latência da memória aumenta de 5 ms para 50 ms, as requisições em trânsito crescem dez vezes, esgotando conexões, threads e filas. Como cada turno envolve múltiplas leituras e gravações, a latência se acumula e pode desencadear falhas em cascata.

A diferença entre 5 ms e 50 ms determina se o sistema consegue escalar de forma confiável, não apenas a rapidez percebida. O kernel multithread proprietário do Tair oferece latência consistentemente baixa, mantém o acesso à memória dentro de limites seguros e evita que a concorrência saia do controle sob carga.

Memória do modelo - List

A memória do modelo armazena o histórico de conversas para o LLM. A entrada do usuário e a resposta do agente de cada turno são registradas e passadas como contexto no próximo ciclo de inferência.

Esses dados ficam armazenados em uma List do Tair, com uma chave por sessão:

Key:  memory:model:{sessionId}
Type: List

Sample data:
[
  {"role": "user",      "content": "Order me a milk tea"},
  {"role": "assistant", "content": "Found 3 nearby milk tea shops...", "cards": [...]},
  {"role": "user",      "content": "That one, less sugar, no ice"},
  {"role": "assistant", "content": "Selected: Jasmine Milk Tea, less sugar, no ice, large..."}
]

Principais operações:

# Append a new conversation record after each turn
RPUSH memory:model:{sessionId} "{conversation_record_JSON}"

# Read the last N turns of conversation as context before model inference
LRANGE memory:model:{sessionId} -{N} -1

# Set the session expiration time (for example, 30 minutes)
EXPIRE memory:model:{sessionId} 1800

Memória de contexto de negócios - Hash

A memória de contexto de negócios armazena o estado estruturado do fluxo de trabalho. A camada de ferramentas do agente e os manipuladores de intenção consultam e atualizam esses dados durante a execução da lógica de negócios.

Esses dados dividem-se em seis submódulos por domínio de negócios e ficam armazenados em um Hash do Tair:

Key:  memory:context:{sessionId}
Type: Hash

Field structure:
{
  "session":      "{Session metadata: user ID, channel, session stage, etc.}",
  "search":       "{Search state: current query, search results, recommended product list, etc.}",
  "order":        "{Order state: cart contents, selected SKUs, item quantities, etc.}",
  "conversation": "{Conversation state: current intent, previous intent, intent switch flag, etc.}",
  "coupon":       "{Coupon info: available coupon list, selected coupons, etc.}",
  "bizState":     "{Business state: delivery address, shipping method, payment status, etc.}"
}

Operações principais:

# Update a specific submodule (for example, the user confirmed a delivery address)
HSET memory:context:{sessionId} bizState "{updated_business_state_JSON}"

# Read a specific submodule
HGET memory:context:{sessionId} order

# Read all context at once (for scenarios that need global information, such as intent recognition)
HGETALL memory:context:{sessionId}

# Set the expiration time
EXPIRE memory:context:{sessionId} 1800

Comparação de estruturas de dados

# Acquire a session-level distributed lock (3-second timeout to prevent blocking)
SET lock:memory:{sessionId} {requestId} NX EX 3

# After acquiring the lock, perform memory read/write operations
HSET memory:context:{sessionId} order "{updated_order_state}"
RPUSH memory:model:{sessionId} "{new_conversation_record}"

# Release the lock after operations complete (use a Lua script to release only the lock you hold)
EVAL
  if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
  else
    return 0
  end

Vantagens de desempenho do kernel proprietário do Tair

As instâncias baseadas em DRAM do Tair (Enterprise Edition) usam um modelo multithread que entrega 3 vezes mais throughput de leitura/gravação do que o Redis Open-Source Edition nas mesmas especificações.

Isso é crucial para cargas de trabalho de agentes de IA, em que uma única conversa dispara dezenas de operações. O modelo single-thread do Redis open source torna-se gargalo sob alta concorrência. O kernel multithread do Tair utiliza totalmente CPUs multicore em um único nó e lida com maior concorrência sem adicionar nós.

Dimensionamento elástico e operações transparentes de cluster

A memória do agente apresenta padrão de muita leitura e pouca escrita. Antes de cada ciclo de inferência, o agente lê todo o histórico de conversas e contexto, enquanto as gravações ocorrem apenas uma vez por turno. A proporção de leitura para escrita geralmente varia de 5:1 a 10:1.

O Tair suporta separação de leitura/gravação no modo cluster, roteia automaticamente leituras para réplicas e gravações para masters. Configure de 1 a 9 réplicas de leitura por shard e escale de 2 a 256 shards. Adicione réplicas ou shards antes de um pico para aumentar o throughput linearmente; reduza-os depois para diminuir custos.

Normal traffic:
  8-shard cluster, 1 read replica per shard -> meets daily business requirements

Spring Festival campaign (5x - 10x peak):
  Option 1: Scale to 5 read replicas per shard -> linear increase in read throughput
  Option 2: Scale to 16 shards + 3 read replicas per shard -> double both read and write capacity

Essas operações são transparentes para a aplicação. A migração de slots tradicional de clusters Redis pode produzir erros -ASK e -TRYAGAIN: qualquer requisição com falha pode interromper uma conversa do agente ou causar perda de memória. As instâncias cloud-native do Tair usam dimensionamento transparente no nível do kernel: os dados migram atomicamente no nível do slot, prevenindo fragmentação. Um componente de controle centralizado coordena a migração para maior eficiência e precisão.

Dimensionamento elástico de largura de banda

A campanha também trouxe desafios de largura de banda. Cada leitura de memória do agente transfere histórico de conversas e contexto de negócios, gerando payloads muito maiores do que leituras de cache típicas. Durante picos, a largura de banda pode tornar-se gargalo antes da CPU ou da memória.

A arquitetura cloud-native do Tair fornece dois níveis de largura de banda elástica:

• Dimensionamento horizontal de largura de banda via balanceadores de carga: Adicione balanceadores de carga (LBs) no modo cluster para aumentar a largura de banda total. Cada LB suporta até 20 Gbps. Para clusters com mais de 8 shards, adicione LBs sob demanda sem interromper conexões.

• Largura de banda burst: Quando o tráfego excede a largura de banda fixa, o sistema escala automaticamente em segundos (até 288 MB/s por nó) e retorna ao normal após o pico. Pague apenas pelo uso real do burst. O burst opera no nível do shard: quando uma hot key causa gargalo em um shard, apenas esse shard escala verticalmente.

Limpeza automática baseada em TTL

Todas as chaves de sessão usam TTL (por exemplo, 30 minutos). Após um pico, o uso de memória cai automaticamente. Combinado com o dimensionamento elástico, isso oferece gerenciamento de recursos totalmente automático: escale para cima no pico, escale para baixo fora do pico e limpe dados expirados.

Com essa abordagem, o serviço de memória permaneceu estável durante todo o pico de tráfego do Festival da Primavera, com latência P99 consistentemente na faixa de milissegundos de um dígito.