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.
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.
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
viaDUMP/RESTORE
. - Operações facilitadas
SCAN
eDUMP/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.