Memcached
Redis x Memcached
Compare recursos, consumo de memória, persistência, escalabilidade e facilidade de uso.
Nesta aula você vai
- Comparar Redis/Valkey e Memcached em dimensões técnicas e operacionais
- Quantificar trade-offs de memória, latência e complexidade para decisões reais
- Recomendar arquitetura híbrida ou consolidada conforme maturidade do time
Redis x Memcached
Objetivos
Nesta aula você vai:
- Confrontar Redis (e Valkey) com Memcached em tabela decisória completa
- Avaliar cenários de coexistência versus consolidação em uma única plataforma
- Sintetizar aprendizados do módulo para escolha informada em novos projetos
Introdução
A rivalidade Redis versus Memcached é, na verdade, sobreposição parcial. Ambos aceleram leituras mantendo dados em RAM; divergem em ambição, modelo de threading, persistência e ecossistema. Muitas empresas consolidaram tudo em Redis/Valkey; outras mantêm Memcached na borda por custo histórico e simplicidade extrema.
Esta aula fecha o módulo Bancos de dados em memória e cache com comparação direta e recomendações de arquitetura — conectando intro (curso 1), Redis profundo (curso 2), Valkey (curso 3) e Memcached (curso 4).
Conteúdo
Comparativo técnico abrangente
| Dimensão | Memcached | Redis / Valkey |
|---|---|---|
| Modelo de dados | String/blob apenas | Strings, hash, list, set, zset, stream, etc. |
| Threading | Multi-threaded nativo | Single-threaded (I/O threads opcionais) |
| Persistência | Não | RDB, AOF |
| Replicação | Não (proxy/cliente) | Replicação nativa, Sentinel, Cluster |
| Sharding | Cliente / Mcrouter | Redis Cluster server-side |
| Protocolo | Texto simples (11211) | RESP (6379) |
| Transações / Lua | Não | MULTI/EXEC, Lua, Functions |
| Pub/Sub | Não | Sim (+ Streams duráveis) |
| TLS / ACL | Via proxy | Nativo (versões modernas) |
| Uso de memória | Slabs — eficiente para itens pequenos uniformes | Encodings adaptativos; overhead em tipos ricos |
| Curva operacional | Baixa para cache puro | Média a alta (HA, persistência) |
| Licença | BSD | Redis: RSAL/SSPL; Valkey: BSD |
Latência e throughput — nuances
Memcached pode vencer em GET/SET massivo paralelo em um nó graças a threads — benchmarks sintéticos frequentemente mostram pico alto em workload 100% leitura de valores pequenos.
Redis/Valkey compensa com:
- Menos round-trips (hash field vs JSON inteiro)
- Pipeline e comandos compostos
- Cluster horizontal sem lógica hash no app
Em produção, latência de rede e serialização na aplicação frequentemente dominam — diferença pura de servidor só aparece sob profiling cuidadoso.
Eficiência de memória
Cenário: cache de objeto com 5 campos, atualização parcial frequente.
| Abordagem | Memória / round-trips |
|---|---|
| JSON inteiro em Memcached | Re-serializa tudo; maior tráfego |
Hash Redis com HSET campo |
Atualização parcial; encoding compacto |
Cenário: milhões de chaves pequenas uniformes (HTML fragments 500 bytes).
| Abordagem | Nota |
|---|---|
| Memcached slabs | Pode ser muito eficiente |
| Redis strings | Competitivo; medir MEMORY USAGE |
Conclusão: não há vencedor universal — medir com dados reais.
Quando consolidar em Redis/Valkey
- Time já opera Redis para sessão/fila — adicionar Memcached aumenta superfície operacional
- Necessidade futura provável de estruturas ou persistência
- Observabilidade unificada (um exporter, um runbook)
- Cloud managed cobre Valkey com mesmo billing account
Quando manter ou adicionar Memcached
- Legacy estável com Mcrouter e SLOs atendidos
- Cache puramente anônimo de página com TTL fixo — zero necessidade de features Redis
- Equipe separada opera cache edge vs data platform
- Benchmark provou ganho mensurável e custo de migração > benefício
Arquitetura híbrida (coexistência)
Possível em transição:
[App] ──► Memcached (fragmentos HTML estáticos)
│
└──► Valkey (sessão, rate limit, fila leve)
Riscos: duas falhas operacionais, dois pools de conexão, inconsistência de documentação. Plano de saída deve definir se destino é consolidação ou estado estável dual.
Valkey na equação
Para novos deploys em 2025+, a pergunta "Redis ou Memcached?" frequentemente vira "Valkey ou Memcached?" — com Valkey assumindo papel de plataforma default BSD e Memcached reservado a nicho de cache volátil extremamente simples ou legado.
| Decisão | Tendência |
|---|---|
| Greenfield cache + sessão | Valkey |
| Greenfield só cache blob volátil | Memcached ainda válido; Valkey também OK |
| Compliance BSD | Valkey > Redis SSPL |
| Legado Memcached saudável | Não migrar sem motivo |
Exemplos práticos
Mesmo dado em ambos — compare mentalmente operações:
Memcached:
printf "set user:42 0 1800 45\r\n{\"name\":\"Ana\",\"role\":\"admin\"}\r\n" | nc -q 1 localhost 11211
printf "get user:42\r\n" | nc -q 1 localhost 11211
Valkey/Redis (hash — update parcial sem reescrever JSON):
redis-cli HSET user:42 name "Ana" role "admin"
redis-cli EXPIRE user:42 1800
redis-cli HGET user:42 role
redis-cli HSET user:42 role "editor"
Checklist final de escolha para seu projeto:
- Listar comandos/features usados hoje
- Medir hit rate, p99 latência, evictions/used_memory
- Validar licença e serviço managed na região
- PoC de 1 semana se dúvida persistir
- Registrar ADR com revisão em 12 meses
Resumo
- Memcached = cache volátil minimalista, multi-threaded, sharding no cliente.
- Redis/Valkey = plataforma de dados em memória com estruturas, persistência e HA.
- Benchmarks de lab não substituem medição em produção com payload e padrão de acesso reais.
- Consolidação em Valkey reduz complexidade operacional na maioria dos greenfields.
- Memcached permanece legítimo onde simplicidade e legado justificam — não por nostalgia, mas por fit mensurável.
- Você concluiu o módulo com base para escolher, operar e evoluir sistemas de cache e memória com critério profissional.