Estruturas de dados do Redis

Objetivos

Nesta aula você vai:

• Conhecer cada tipo nativo do Redis e seus comandos fundamentais
• Relacionar estruturas a casos de uso reais (sessão, fila, ranking, event log)
• Evitar armadilhas de complexidade algorítmica e modelagem incorreta

Introdução

O diferencial competitivo do Redis sobre caches simples está nas estruturas de dados nativas: operações que seriam múltiplas queries ou locks na aplicação tornam-se um único round-trip atômico no servidor. Modelar bem — escolher hash em vez de JSON gigante em string, sorted set em vez de lista ordenada na app — define eficiência de memória e latência.

Conteúdo

Strings — mais do que texto

Tipo mais básico; valores até 512 MB. Suporta operações atômicas numéricas e bitwise.

SET contador 0
INCR contador
INCRBY contador 10
GET contador

SET flag:feature-x "1" EX 86400 NX

SET NX EX é base de distributed lock leve. Strings também armazenam JSON serializado quando não há necessidade de campos parciais.

Hashes — objetos com campos

Ideal para entidades com atributos mutáveis (usuário, sessão, produto resumido):

HSET usuario:42 nome "Ana" email "ana@ex.com" plano "pro"
HGET usuario:42 email
HGETALL usuario:42
HINCRBY usuario:42 login_count 1

Lists — filas FIFO/LIFO

Lista duplamente encadeada de strings. LPUSH/RPOP para fila; LRANGE para inspeção:

LPUSH fila:tarefas "enviar-email"
LPUSH fila:tarefas "gerar-relatorio"
BRPOP fila:tarefas 0

BRPOP bloqueia até haver elemento — worker eficiente sem polling agressivo. Listas não são ideais para ranking (use sorted set) nem para membership rápido (use set).

Sets — conjuntos únicos

Sem ordem; SADD, SISMEMBER, SINTER, SUNION:

SADD tags:post:100 redis cache performance
SISMEMBER tags:post:100 redis
SINTER tags:post:100 tags:post:200

Úteis para tags, deduplicação (SADD visitantes:2026-07-08 user-42 retorna 0 se já existia) e relações many-to-many leves.

Sorted sets (ZSET) — score ordenado

Cada membro tem score numérico; ordem por score em O(log N):

ZADD leaderboard 2850 "player_ana"
ZADD leaderboard 3100 "player_bruno"
ZREVRANK leaderboard "player_ana"
ZRANGEBYSCORE leaderboard 3000 +inf WITHSCORES

Casos: rankings, filas prioritárias, sliding window rate limit (scores = timestamps).

Streams — log append-only com consumer groups

Evolução para event sourcing leve e filas duráveis:

XADD pedidos * cliente_id 42 total 199.90
XREAD COUNT 10 STREAMS pedidos 0
XGROUP CREATE pedidos grupo-pagamento $ MKSTREAM
XREADGROUP GROUP grupo-pagamento worker-1 COUNT 1 STREAMS pedidos >

Streams mantêm histórico (até trimming), ACK por consumidor e reprocessamento de pending — superior a listas para pipelines críticos.

Tabela de decisão rápida

Exemplos práticos

Modelar carrinho de compras:

HSET carrinho:sessao-abc produto:1 2 produto:7 1
HINCRBY carrinho:sessao-abc produto:1 1
HLEN carrinho:sessao-abc
EXPIRE carrinho:sessao-abc 7200

Rate limit com janela deslizante via sorted set:

ZADD rl:user:42 1710000000 "req-1" 1710000001 "req-2"
ZREMRANGEBYSCORE rl:user:42 0 1709999940
ZCARD rl:user:42

Inspecionar tipo e encoding interno:

OBJECT ENCODING usuario:42
TYPE usuario:42

Resumo

• Redis oferece strings, hashes, lists, sets, sorted sets, streams e tipos auxiliares (HLL, bitmap, geo).
• A escolha correta reduz memória, round-trips e bugs de concorrência na aplicação.
• Hashes para objetos; ZSET para ordem por score; Streams para filas duráveis com grupos.
• Comandos como KEYS, SMEMBERS em sets enormes ou LRANGE em listas longas exigem cautela — prefira SCAN, paginação e trimming.
• Próximas aulas tratam persistência e replicação — estruturas só persistem se RDB/AOF estiverem configurados.