← Voltar para o blog

Apresentando o Rump: sincronize duas bases de dados Redis em tempo real com dumps

Publicado por Marco Lisci em

Estamos empolgados em anunciar nosso primeiro projeto open source: o Rump!

O Rump é uma pequenina ferramenta com um foco simples: extrair os dados em tempo real de um ElastiCache do Redis Cluster.

Tivemos esse problema ao tentar sincronizar nossos contêineres de teste do Redis com nosso cluster de produção. Na Sticker Mule, usamos muito o Docker e CoreOS, contando com um cluster ElastiCache para quando precisamos do Redis em produção.

Ultimamente, queríamos deixar o ambiente de teste o mais próximo possível do nosso ambiente de produção, e o Redis é parte disso. Veja a jornada que acabou levando ao Rump.

Não bloquear

Tínhamos um requerimento simples: não bloquear a produção ao obter os dados. O fato de o Redis trabalhar em um só fio é um aspecto importante a ter em mente.

Surpreendentemente, descobrimos que o ElastiCache envia com alguns comandos desativados. Basicamente, todos os comandos que você pode usar para transferir dados com segurança.

Rump Redis sincronização

BGSAVE

O jeito padrão de forçar manualmente um backup de uma base de dados Redis é gerando um BGSAVE e esperando ele terminar no pano de fundo, o que é uma operação sem bloqueio. Infelizmente, ela fica desativada, a menos que você use a implementação interna da AWS do recurso de snapshot.

SLAVEOF

A configuração de réplicas é outra opção interessante que o Redis oferece, e teria sido a escolha perfeita para nós.

O plano era temporariamente configurar os testes de contêineres Redis como réplicas do nosso cluster de produção, obtendo dados em tempo real. Infelizmente, SLAVEOF também está desativado e não há forma de adicionar réplicas a um exemplo de ElastiCache.

Ferramentas existentes

Há muitas ferramentas incríveis para o Redis que procuram simplificar a administração de servidores do Redis, dumping para JSON, etc.

O problema é que a maioria das ferramentas estáveis mantidas usam o comando KEYS para obter chaves e a seguir operar com elas. O comando KEYS tem uma complexidade O(N), bloqueando bastante o Redis quando o N está alto, até todas as chaves serem retornadas. Contêineres de sincronização são criados e destruídos frequentemente, e temos uma boa quantidade de chaves, não queremos fazer um DoS do nosso próprio servidor.

rump-logo-600w

Era óbvio que precisávamos de uma ferramenta simples para fazer somente a sincronização. Começamos a testar com SCAN para obter as chaves e DUMP/RESTORE para obter/definir valores.

SCAN é um comando O(1), de execução segura em um servidor de produção para obter todas as chaves, e por causa disso sua implementação precisa ser diferente de KEYS. SCAN retorna um grupo de chaves atualmente presentes no DB, e um cursor para o próximo grupo.

DUMP/RESTORE tornam a tarefa de ler/escrever valores independente do tipo de chave.

Tendo isso em mente, veja como o RUMP contribui:

  • Leitura progressiva e sem bloqueios das chaves através de SCAN.
  • Operações com valores independentes TYPE via DUMP/RESTORE.
  • Operações facilitadas SCAN e DUMP/RESTORE.
  • A leitura do servidor-fonte e a comunicação ao servidor-destino são simultâneas. O Rump não armazena todas as chaves antes de comunicá-las para o servidor-destino.
  • Binary cross-platform, sem dependências.
  • Pegada mínima, filosofia UNIX, realiza uma só coisa com duas bandeiras.

Esperamos que a ferramenta seja útil para quem estiver tendo as mesmas dificuldades que nós tivemos. Muitíssimo obrigado ao Redis por trabalhar com uma variedade tão grande de comandos!

P.S.: Se isso é do seu interesse e você está procurando uma organização onde pessoas talentosas podem ter prazer em trabalhar, estamos contratando.

← Voltar para o blog

Gostou deste post? Comente no Stimulus.