Cargas de trabalho de cache e fila com Redis no Dockup

As cargas de trabalho de cache e fila com Redis podem usar o mesmo serviço gerenciado de Redis, mas têm requisitos de consistência diferentes. Um cache geralmente pode ser reconstruído após uma perda. Uma fila pode representar trabalho que não deve ser descartado silenciosamente nem processado duas vezes.

O Dockup provisiona o Redis como um banco de dados gerenciado, oferece operações de consulta de tamanho e logs, dá suporte a fluxos de backup e migração de nós e pode conectar o banco de dados aos serviços da aplicação por meio da rede privada do projeto.

Como provisionar um Redis gerenciado?

Crie o Redis no workspace selecionado:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Confirme o destino do banco de dados:

dockup db list --json

Armazene as informações de conexão retornadas fora do controle de versão e associe-as ao serviço consumidor como um secret:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

O redeploy cria um novo container da aplicação com o ambiente atualizado. Reiniciar o container antigo não aplica um novo valor desejado armazenado.

Use bancos de dados ou instâncias Redis separados quando o comportamento de eviction do cache e a retenção de filas críticas não devem competir pela mesma memória. O isolamento também simplifica o diagnóstico de incidentes e o controle de acesso.

Quando usar o Redis como cache?

Um cache reduz o trabalho repetido ou a latência ao armazenar dados derivados. A fonte de verdade continua em outro lugar, geralmente no PostgreSQL, MySQL, MongoDB, em uma API externa ou em um cálculo determinístico.

Um bom design de cache define:

• Formato e namespace das chaves do cache.
• Tempo de vida.
• Nível máximo aceitável de desatualização.
• Gatilho de invalidação.
• Comportamento em caso de cache miss.
• Comportamento quando o Redis está indisponível.
• Proteção contra thundering herd.
• Quais dados nunca devem ser armazenados em cache.

Falha	Comportamento seguro do cache
Chave ausente	Recalcular ou ler a fonte de verdade
Redis indisponível	Degradar para a fonte com proteção contra excesso de requisições
Entrada desatualizada	Expirar ou invalidar
Alteração na serialização	Criar uma versão do namespace das chaves
Pressão de memória	Remover primeiro os dados que podem ser reconstruídos
Chave muito acessada	Adicionar cache local, sharding ou request coalescing

Não torne a aplicação inteira indisponível apenas porque um cache opcional está fora do ar. Use timeouts limitados e caminhos de fallback. Por outro lado, não oculte todas as falhas: uma indisponibilidade prolongada do cache pode sobrecarregar o banco de dados de origem.

O que muda quando o Redis é usado como job queue?

Uma fila representa trabalho pendente, portanto a aplicação precisa definir a semântica de entrega e recuperação. O Redis é um servidor de estruturas de dados; as garantias dependem da biblioteca de filas e do protocolo dos workers.

Decida:

1. Quando um job é considerado aceito?
2. Quando ele é confirmado?
3. O que acontece se um worker falhar depois de executar o efeito colateral, mas antes da confirmação?
4. Como os retries são atrasados e limitados?
5. Para onde vão os jobs que falharam permanentemente?
6. Como tornar segura a execução duplicada?
7. Como observar a profundidade da fila?
8. É possível reconstruir o payload do job?

Crie workers idempotentes. Uma captura de pagamento, um e-mail ou uma importação de dados pode ser entregue mais de uma vez após uma falha. Use uma chave de idempotência de negócio e registre a conclusão no banco de dados que é a fonte de verdade.

Separe os nomes das filas por carga de trabalho e prioridade. Um job de mídia lento não deve impedir o processamento de redefinição de senha ou de webhooks. Evite colocar secrets nos payloads dos jobs quando um ID de referência for suficiente.

Uma implantação de cache e fila com Redis deve documentar quais chaves são descartáveis e quais representam trabalho de negócio.

Como a rede privada conecta os serviços ao Redis?

Ative a rede do projeto:

dockup network enable production --json

O serviço Redis fica acessível pelo hostname estável <slug>.internal a partir dos serviços no mesmo projeto. Faça o redeploy da aplicação para que o Dockup possa injetar as variáveis de conexão internas.

Para tornar o Redis acessível apenas de forma privada:

dockup db private production/app-redis --json

Restaure o listener público quando necessário:

dockup db private production/app-redis --off --json

A rede privada remove o caminho pela internet pública para o tráfego dentro do mesmo projeto, mas não substitui a autenticação. Mantenha as informações de conexão do Redis em segredo e restrinja quais serviços recebem esse material.

Projetos diferentes não conseguem acessar a rede privada uns dos outros. Esse limite pode ser útil quando produção e staging não devem compartilhar chaves de cache nem trabalhos de fila.

Consulte rede privada e domínios internos para conhecer o modelo completo.

Como as falhas do Redis devem afetar a aplicação?

Classifique a carga de trabalho antes de escrever o código de recuperação.

Carga de trabalho	Tolerância à perda	Resposta à indisponibilidade
Cache de fragmentos HTML	Alta	Reconstruir a partir da fonte
Session store	Baixa a média	Pode desconectar os usuários; planejar um fallback
Contadores de rate limit	Depende da política	Definir explicitamente se a falha será aberta ou fechada
Job queue	Baixa	Parar de aceitar jobs ou persistir em outro local
Distributed lock	Muito baixa para seções críticas	Usar fencing/idempotência
Cache de funcionalidades	Alta	Usar um valor padrão ou a fonte

Um cliente Redis não deve fazer retry para sempre. Retries longos podem consumir todos os workers da aplicação e transformar um incidente do Redis em uma indisponibilidade completa. Os workers da fila devem aplicar backoff, expor o trabalho que falhou e parar após uma política definida.

Inspecione o tamanho do Redis e os logs de runtime da aplicação consumidora:

dockup db size production/app-redis --json
dockup logs production/api --json

O crescimento do tamanho pode indicar expiração ausente, profundidade descontrolada da fila, payloads grandes demais ou namespaces abandonados. Não trate o restart do banco de dados como primeira resposta a timeouts da aplicação; verifique primeiro a configuração, a rede e o comportamento do cliente.

Como backup, migração e monitoramento se relacionam com o Redis?

O Dockup disponibiliza o fluxo de backup do banco de dados gerenciado:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

A adequação de um backup do Redis ao objetivo de recuperação da carga depende do significado dos dados. Um backup de cache pode ser desnecessário. Um backup de fila ainda pode perder trabalhos aceitos depois do ponto do backup. Quando possível, jobs críticos para o negócio devem ter um registro recuperável fora da fila.

Mova o Redis entre nós com:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Planeje o impacto da migração sobre clientes e workers. Confirme se o comportamento de reconexão, retry e idempotência funciona antes de migrar para produção.

Monitore métricas no nível da aplicação além do tamanho do banco de dados:

• Taxa de acerto do cache.
• Latência de cache miss.
• Evictions.
• Profundidade da fila e idade do job mais antigo.
• Contagens de jobs concluídos, com retry e com falha.
• Concorrência dos workers.
• Erros de conexão com o Redis.
• Tamanho dos payloads.

O Dockup mede o consumo de CPU, RAM e disco por minuto em relação ao saldo do plano. O plano Pro recomendado custa US$ 20 por mês e inclui US$ 20 em créditos de uso, mas as métricas da carga de trabalho — não o nome do plano — devem orientar as decisões de capacidade.

Qual é uma checklist segura de produção para Redis?

Antes do lançamento, verifique:

1. O destino exato project/db.
2. As responsabilidades de cache e fila estão documentadas.
3. A URL de conexão é um secret mascarado.
4. A política de rede privada foi definida.
5. Todo cache tem TTL ou invalidação explícita.
6. Os workers da fila são idempotentes.
7. O comportamento de retry e dead letter é definido pelo sistema de filas.
8. Existem alertas para tamanho e profundidade da fila.
9. O valor e as limitações do backup são conhecidos.
10. Restart e migração dependem de aprovação.

Exemplo de separação entre cache e fila

Uma aplicação pequena pode começar com um único banco de dados Redis quando o risco for baixo, mas deve usar prefixos de chave claros:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

À medida que a carga cresce, separe o estado de filas críticas do estado de cache sujeito a eviction agressivo. Esse é um limite operacional, não apenas uma preferência de nomenclatura.

Um design bem-sucedido de cache e fila com Redis torna previsível o comportamento da aplicação quando o Redis está rápido, lento, vazio ou indisponível.

Para operações relacionais na fonte de verdade, consulte PostgreSQL gerenciado. Para conhecer opções mais amplas de capacidade, consulte estratégias de escalabilidade de bancos de dados. Use a referência da CLI do Dockup para consultar os comandos de banco de dados atuais.

Defina a evolução de chaves e payloads

Os dados de cache e de filas sobrevivem a um único processo da aplicação. Uma nova versão pode ler chaves gravadas pela versão anterior durante uma implantação blue-green. Versione os namespaces das chaves e os payloads dos jobs para que ambas as versões possam coexistir.

Nas filas, inclua uma versão do payload e mantenha os workers capazes de processar pelo menos as versões que ainda possam estar aguardando. Um rollback da implantação pode restaurar o código antigo enquanto jobs no novo formato permanecem no Redis. Sem compatibilidade, o rollback da aplicação pode aumentar as falhas.

Teste a pressão sobre os recursos de forma deliberada

Em um ambiente que não seja de produção, teste chaves ausentes, respostas lentas do Redis, resets de conexão, acúmulo de jobs na fila, entregas duplicadas e uma condição de memória cheia ou quase cheia. Observe se a aplicação falha de forma aberta ou fechada, faz retry ou sobrecarrega outra dependência.

Um runbook de cache e fila com Redis deve definir limites para tentativas de retry e concorrência. Loops de retry ilimitados podem consumir todos os workers e tornar a recuperação mais difícil do que o incidente original.

Mantenha um caminho de recuperação pela fonte de verdade

Para jobs críticos, armazene estado suficiente no banco de dados principal para reconstruir o trabalho após uma perda do Redis. Uma fila deve acelerar o processamento, não se tornar o único registro de que uma ação do cliente ocorreu.

Comece com uma implantação verificável

Provisione o Redis em um projeto que não seja de produção, teste o fallback do cache e a entrega duplicada de jobs e torne a política de falhas explícita antes de direcionar trabalhos críticos para o sistema.

Comece gratuitamente em app.dockup.ai. O plano Free custa US$ 0 por mês, inclui US$ 10 em créditos iniciais e permite um workspace, três bancos de dados e três implantações.

FAQ

O Dockup pode criar um Redis gerenciado?

Sim. Use o comando de criação de banco de dados gerenciado com o tipo redis e conecte a aplicação usando as informações de conexão retornadas, armazenadas como um secret.

Os dados de cache e fila devem compartilhar uma única instância Redis?

Isso é possível em uma carga pequena e de baixo risco, mas a separação é mais segura quando eviction do cache e retenção de filas críticas têm requisitos diferentes de disponibilidade e memória.

O Redis garante que um job enfileirado seja executado exatamente uma vez?

Não se deve presumir uma garantia geral de execução exatamente uma vez. A semântica de entrega depende da biblioteca de filas e do design dos workers; portanto, torne os efeitos colaterais idempotentes.

O Redis pode usar a rede privada do Dockup?

Sim. Ative a rede do projeto, faça o redeploy dos serviços consumidores para obter as variáveis internas e, opcionalmente, torne o banco de dados Redis acessível apenas de forma privada.

Um backup do Redis é suficiente para uma fila de jobs crítica?

Não necessariamente. Ele representa um ponto no tempo e pode não incluir trabalhos aceitos mais recentemente. Mantenha registros de origem recuperáveis e defina a recuperação de jobs no nível da aplicação.