Uma fila de jobs permite executar tarefas fora do fluxo imediato de uma requisição: enviar notificações, processar arquivos ou sincronizar dados. Mas, quando entram mais jobs do que os consumidores conseguem concluir, forma-se um backlog. O atraso pode ficar visível em confirmações tardias, dados desatualizados ou tarefas que nunca terminam, com impacto tanto para os usuários quanto para as equipes que operam a aplicação.
Para decidir como agir, não basta observar quantas mensagens estão pendentes. Importam a antiguidade, a velocidade com que chegam e são concluídas, o tipo de trabalho e o estado das dependências. Adicionar consumidores pode ajudar quando falta capacidade, mas também pode multiplicar as consultas a um banco de dados já sobrecarregado. Uma resposta segura começa por medir e reconhecer o padrão.
O que o backlog revela e quais métricas estão faltando
O número de jobs pendentes é um retrato, não uma explicação. Pode crescer durante um pico e diminuir depois sem intervenção, ou permanecer estável enquanto o job mais antigo fica cada vez mais velho. Por isso, ao avaliar como controlar o backlog de uma fila PHP, convém observar em conjunto:
- Taxa de entrada: jobs aceitos por unidade de tempo.
- Taxa de saída: jobs concluídos por unidade de tempo, diferenciando os concluídos das tentativas com falha.
- Antiguidade: há quanto tempo o job mais antigo está esperando, além dos percentis de espera, se estiverem disponíveis.
- Duração do processamento: quanto tempo cada tipo de job leva e como essa duração varia.
- Erros e novas tentativas: proporção de falhas, número de tentativas e presença de jobs enviados para uma fila de erros ou quarentena.
- Estado dos consumidores e das dependências: processos ativos, reinicializações, uso de CPU e memória, conexões ao banco de dados e latência de serviços externos.
A taxa de saída deve representar trabalho útil concluído: contar cada tentativa como uma tarefa drenada pode ocultar um ciclo de falhas e novas tentativas. Também é importante segmentar por fila ou classe de tarefa. Uma média global pode disfarçar que um tipo de job está bloqueando os demais.
Diagnostique o padrão antes de alterar a capacidade
Compare as métricas em uma janela de tempo adequada à operação e com o comportamento habitual do sistema. Os padrões orientam a investigação, mas, por si só, não comprovam a causa.
- Entrada persistentemente superior à saída: pode faltar capacidade, o volume pode ter aumentado ou a duração dos jobs pode ter se prolongado. Revise as alterações recentes, a composição do tráfego e os tempos por tipo de tarefa.
- Consumidores ativos, mas saída quase nula: procure processos bloqueados, esperas indefinidas, deadlocks, esgotamento do pool de conexões ou chamadas externas sem limites de tempo. Revise os logs e os traces correlacionados pelo identificador do job.
- Aumento da duração e da latência das dependências: os consumidores podem estar esperando pelo banco de dados, por uma API ou pelo armazenamento. Mais processos podem aumentar a contenção e piorar a latência.
- Falhas repetidas nos mesmos jobs: pode tratar-se de dados inválidos, uma condição irrecuperável ou um defeito. Verifique a política de novas tentativas: tentar novamente cedo demais pode criar uma tempestade de carga.
- Uma fila cresce enquanto as outras avançam: revise as prioridades, a distribuição dos consumidores e se uma classe de trabalho está monopolizando os recursos.
Procure também alterações de configuração e implantações recentes. Confirme se a telemetria distingue um consumidor ocupado de um consumidor ativo que não progride; uma verificação de processo ativo não garante que os jobs estejam sendo concluídos.
Estime a capacidade de drenagem com dados observados
Se a taxa de saída sustentada for superior à taxa de entrada, a fila poderá diminuir enquanto essa diferença se mantiver. Como aproximação operacional, o tempo para processar o backlog depende do número de jobs pendentes dividido pela capacidade líquida de drenagem: capacidade de saída menos entrada no mesmo período. Se essa diferença for zero ou negativa, aumentar o tempo de espera não resolverá o acúmulo.
A estimativa é indicativa, não uma promessa de horário de recuperação. Ela pressupõe que o ritmo se mantenha e que os jobs tenham uma composição e um custo semelhantes. Alguns jobs longos, novas tentativas ou limites de uma dependência podem alterar o resultado. Use taxas observadas sob carga real e faça uma nova estimativa após cada intervenção. Para tarefas com custos distintos, calcule por classe de trabalho ou meça o tempo de serviço, não apenas o número de mensagens.
Intervenha por etapas e com limites
Priorize medidas reversíveis e limitadas. Antes de alterar o número de consumidores, defina qual impacto cada dependência pode tolerar e como reverter a alteração.
- Contenha novas entradas, se possível: pause produtores não essenciais, aplique limites ou adie tarefas de baixa prioridade. Evite descartar jobs sem uma regra de negócio, um registro e um mecanismo de recuperação.
- Isole jobs problemáticos: limite as tentativas, aplique um intervalo progressivo quando apropriado e encaminhe falhas persistentes para uma fila de erros que possa ser revisada. Não ignore esses jobs: eles podem exigir correção e reprocessamento.
- Proteja as prioridades: separe tarefas urgentes das de manutenção ou processamento em massa e verifique se as prioridades não condenam as filas menos urgentes a esperar indefinidamente.
- Ajuste a concorrência gradualmente: altere o número de consumidores em pequenos incrementos e observe o desempenho e a saturação. Mantenha limites compatíveis com as conexões disponíveis, CPU, memória e cotas dos serviços externos.
- Corrija a causa: se houver consultas lentas, bloqueios ou chamadas sem timeout, resolva esse gargalo antes de manter mais processos trabalhando em paralelo.
A idempotência é especialmente importante quando um job pode ser executado mais de uma vez. Projete efeitos externos e gravações para tolerar novas tentativas ou incorpore mecanismos de deduplicação adequados. Confirme também o que acontece se o consumidor parar depois de executar o efeito, mas antes de confirmar a mensagem.
Defina limites e um procedimento de recuperação
Estabeleça limites com base nos requisitos de serviço, não em um número universal. Um alerta pode combinar a antiguidade máxima ou o percentil de espera, a tendência do backlog, a diferença entre entrada e saída e a taxa de erros. A antiguidade costuma estar mais ligada ao impacto para o usuário do que uma contagem isolada; o volume ajuda a dimensionar a magnitude.
Documente quem intervém, quais filas pode pausar, quais dependências deve consultar e quais alterações exigem aprovação. Durante o incidente, registre horário, hipótese, ação e efeito observado. Após cada ajuste, verifique se a taxa de saída aumenta sem que a latência do banco de dados, os erros externos, o uso de recursos ou as falhas da aplicação subam para níveis inaceitáveis.
Considere a recuperação confirmada quando a antiguidade e o volume diminuírem de forma sustentada, os jobs forem concluídos corretamente e as dependências voltarem a um nível estável. Não declare o problema resolvido apenas porque o contador diminuiu: mensagens podem ter sido descartadas ou acumuladas em outra fila.
Lista de verificação para evitar outro acúmulo
- As taxas de entrada e de saída útil, a antiguidade, a duração e as novas tentativas são medidas por fila?
- Os jobs têm limites de tempo e uma política de novas tentativas finita e adequada?
- Há alertas para falta de progresso, não apenas para o volume?
- A concorrência máxima respeita os limites das dependências compartilhadas?
- É possível isolar uma classe problemática sem interromper todo o processamento?
- Existe um procedimento documentado para pausar, retomar e reprocessar com segurança?
- As métricas e os efeitos colaterais são revisados após alterações de código, carga ou configuração?
Uma fila saudável não é necessariamente uma fila vazia: pode haver variações normais. O critério prático é que os jobs sejam concluídos dentro do nível de serviço previsto, que as falhas sejam visíveis e que o sistema mantenha margem para absorver picos. Medir esse comportamento permite agir antes que um acúmulo se transforme em uma interrupção para os usuários.
