KeyDB

Recursos exclusivos

Explore Active Replication, armazenamento FLASH e outras funcionalidades que distinguem o KeyDB do Redis convencional.

Intermediário 40 min 30 pontos Leitura 0%

Nesta aula você vai

  • Explicar o modelo de Active Replication e seus trade-offs
  • Descrever como o FLASH estende capacidade além da RAM
  • Avaliar quando recursos exclusivos justificam adoção do KeyDB

Recursos exclusivos

Objetivos

Nesta aula você vai:

  • Dominar o conceito de Active Replication e compará-lo com replicação Redis clássica
  • Entender o tier FLASH e quando usá-lo sem destruir latência
  • Decidir se recursos exclusivos do KeyDB resolvem problemas que multithread sozinho não resolve

Introdução

Toda edição especial de um clássico traz material inédito: notas de rodapé, capítulo banido, prefácio do autor. O KeyDB não é apenas Redis acelerado — carrega capítulos extras que o original não publicou. Active Replication e FLASH são os mais citados; conhecê-los separa quem escolhe KeyDB por benchmark de quem escolhe por arquitetura.

Esta aula lê esses capítulos inéditos com olhar de engenheiro, não de colecionador.

Conteúdo

Active Replication

No Redis tradicional:

Master (leitura + escrita) ──► Réplicas (somente leitura)
         │
    Failover manual/automático (Sentinel/Cluster)

No Active Replication do KeyDB:

Nó A (leitura + escrita) ◄──► Nó B (leitura + escrita)
         sincronização bidirecional

Ambos os nós aceitam escrita. Alterações propagam-se entre eles. Útil para:

  • Multi-region write com latência local de escrita
  • Eliminar single point of write em topologias específicas
  • Cenários de disaster recovery com promotability instantânea
Aspecto Replicação Redis Active Replication KeyDB
Escrita Um master Múltiplos nós
Conflitos Não aplicável (write único) Possíveis — última escrita pode prevalecer
Complexidade Bem documentada Exige desenho cuidadoso
Caso de uso Leitura escalável Escrita distribuída

Atenção: escrever a mesma chave em dois nós simultaneamente pode gerar divergência temporária. Aplicações devem evitar hot keys globais ou usar chaves regionais (cart:br:123, cart:eu:123).

Configuração simplificada (dois nós):

# Nó 1
active-replica yes
replicaof node2 6379

# Nó 2
active-replica yes
replicaof node1 6379

Teste failover, particionamento de rede e comportamento sob split-brain antes de produção.

FLASH Storage — RAM estendida por SSD

O recurso FLASH do KeyDB permite armazenar chaves além da capacidade de RAM, usando SSD como tier secundário. Chaves "quentes" permanecem em memória; chaves "frias" migram para disco.

Analogia literária: a mesa de trabalho (RAM) guarda os manuscritos em edição; o arquivo (SSD) guarda o acervo completo. Consultas frequentes não atravessam o corredor; consultas raras aceitam a caminhada.

Parâmetro Efeito
Limite de memória configurado Chaves excedentes vão para FLASH
Latência de chave em FLASH Ordem de magnitude maior que RAM
Caso ideal Dataset grande, acesso skewed (80/20)

Habilite com cautela:

maxmemory 8gb
storage-provider /path/to/flash/dir 8gb

Não use FLASH para:

  • Cache de sessão com SLA de sub-milissegundo
  • Filas de mensagens de baixa latência
  • Contadores de rate limiting em tempo real

Use FLASH para:

  • Catálogos enormes com leitura esporádica
  • Feature flags e configurações raramente acessadas
  • Ambientes com orçamento de RAM limitado e tolerância a latência variável

TLS e criptografia em trânsito

KeyDB oferece suporte nativo a TLS para conexões cliente-servidor e replicação — relevante para compliance sem proxy sidecar. Configure certificados em keydb.conf e valide performance (handshake TLS tem custo).

Subskripsões e MVCC (conforme versão)

Versões recentes exploram otimizações de leitura e notificações. Consulte release notes — o KeyDB evolui mais rápido que manuais de curso. O princípio permanece: verificar documentação da versão exata implantada.

Árvore de decisão

Preciso de mais throughput em CPU?
├── Sim, e compatibilidade Redis é crítica → KeyDB multithread
│   └── Também preciso escrever em 2+ regiões? → Active Replication
│   └── Dataset > RAM com acesso frio? → FLASH
└── Não, gargalo é rede/memória → Otimizar Redis ou sharding

Coexistência com Redis

Nada impede Redis para workloads críticos (módulos, cluster maduro) e KeyDB para workloads de cache volumoso com FLASH. Arquiteturas híbridas são válidas quando requisitos conflitam.

Resumo

  • Active Replication permite escrita em múltiplos nós KeyDB, útil em cenários multi-region com gestão cuidadosa de conflitos
  • FLASH estende capacidade para SSD, adequado a dados frios — nunca para workloads de latência extrema
  • TLS nativo facilita compliance sem camadas extras de proxy
  • Recursos exclusivos justificam KeyDB além do multithread quando replicação ativa ou tier de storage resolvem dores reais
  • Valide sempre em staging: Active Replication e FLASH introduzem complexidade operacional que benchmarks de QPS não revelam