Redis vs KeyDB

Objetivos

Nesta aula você vai:

• Conhecer o KeyDB e sua relação histórica com o Redis
• Entender Active Replication e multithreading como diferenciais
• Decidir quando KeyDB é alternativa viável ao Redis tradicional

Conteúdo

O irmão que corre em paralelo

Na família dos bancos em memória compatíveis com Redis, o KeyDB é o irmão que decidiu que um único thread não bastava. Criado pela EQ Alpha Ltd., o KeyDB partiu do código-fonte Redis e adicionou multithreading real e Active Replication — permitindo que múltiplos nós aceitem escritas simultaneamente.

É uma narrativa familiar no ecossistema: assim como Valkey e DragonflyDB, o KeyDB questiona limitações arquiteturais do Redis original. Cada solução, porém, traz sua própria combinação de trade-offs.

O que o KeyDB adiciona ao Redis

Multithreading: como funciona

KeyDB distribui comandos entre threads de worker, similar em espírito ao DragonflyDB, mas com abordagem diferente — mantendo maior compatibilidade com o código-base Redis:

┌─────────────────────────────────────────┐
│              KeyDB                       │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │Worker 1 │ │Worker 2 │ │Worker N │   │
│  │ keys A-M│ │ keys N-Z│ │  ...    │   │
│  └─────────┘ └─────────┘ └─────────┘   │
│       ▲           ▲           ▲         │
│       └───────────┴───────────┘         │
│            Dispatcher de conexões        │
└─────────────────────────────────────────┘

Configuração do número de threads:

# keydb.conf
server-threads 4

# Ou via linha de comando
keydb-server --server-threads 4 --port 6379

Teste com redis-cli (protocolo compatível):

redis-cli -h keydb.local -p 6379

# Comandos idênticos ao Redis
SET contador:visitas 0
INCR contador:visitas
GET contador:visitas

# Pipeline para testar throughput multi-thread
redis-cli --pipe < commands.txt

Active Replication: múltiplos mestres

No Redis tradicional, apenas o master aceita escritas; replicas são read-only. KeyDB introduz Active Replication: dois ou mais nós aceitam escritas e sincronizam bidirecionalmente.

┌──────────┐     Active Repl.     ┌──────────┐
│ KeyDB A  │◄────────────────────►│ KeyDB B  │
│ (writes) │                      │ (writes) │
└──────────┘                      └──────────┘
     ▲                                  ▲
     │         Aplicações               │
     └──────────────┬───────────────────┘
                    │
              Load Balancer

Vantagem: elimina o master único como ponto de contenção de escrita.

Risco: conflitos de escrita na mesma chave entre nós — exige disciplina da aplicação (chaves por região, ou aceitar last-write-wins).

Configuração:

# Nó A
keydb-server --port 6379 --active-replica yes --replicaof keydb-b 6379

# Nó B
keydb-server --port 6379 --active-replica yes --replicaof keydb-a 6379

Performance comparativa

Hardware: 8 cores, 32 GB RAM, valores de 256 bytes. Benchmark com redis-benchmark.

# Benchmark KeyDB
redis-benchmark -h keydb.local -p 6379 -t set,get -n 500000 -c 50 -q

Ganhos são proporcionais ao número de cores e ao ratio de leitura/escrita. Workloads com Lua scripts complexos ou transações MULTI/EXEC podem não escalar linearmente.

Compatibilidade com ecossistema Redis

KeyDB mantém compatibilidade com a maioria dos comandos Redis e funciona com clientes padrão:

KeyDB vs DragonflyDB vs Valkey

Quando escolher KeyDB

• Precisa de multi-master com escritas em múltiplos nós
• Servidor multi-core com Redis single-thread saturado
• Migração de Redis com mínima alteração de código e clientes
• Licença BSD é requisito e Valkey não atende necessidade de Active Replication

Quando evitar KeyDB

• Depende de Redis Cluster para sharding horizontal
• Usa módulos Redis proprietários (RedisJSON, RediSearch)
• Precisa de ecossistema com amplo suporte comercial (Redis Enterprise, Valkey via cloud)
• Workloads com transações complexas em chaves compartilhadas entre nós Active Replication

Operação prática

# Verificar threads ativos
redis-cli INFO server | grep threads

# Monitorar replicação ativa
redis-cli INFO replication

# Verificar latência P99
redis-cli --latency-history -i 1

# Failover manual (promover réplica)
redis-cli REPLICAOF NO ONE

Resumo

• KeyDB é fork BSD do Redis com multithreading real e Active Replication
• Multi-master elimina gargalo de escrita única, mas exige cuidado com conflitos
• Compatível com clientes Redis padrão — migração relativamente simples
• Avalie contra DragonflyDB (throughput) e Valkey (comunidade) conforme prioridades

Para refletir

Active Replication parece resolver o problema do master único. Em um sistema com escritas concorrentes na mesma chave de estoque (produto:1001:qtd), o que poderia dar errado?