Filas de tarefas e balanceamento

1) Porquê as filas de tarefas

• Suaviza os picos, o tampão entre a frente e os subistemas pesados.
• Estabiliza a SLA: prioridades e isolamento das classes de carga.
• Simplifica a resistência a falhas: retraí, DLQ, reaproximação.
• Escala horizontal: adicione os workers sem alterar a API.

Domínios típicos: processamento de pagamentos, notificação, geração de relatórios/mídia, pós-processamento ETL/ML, integração com APIs externas.

2) Modelo e conceitos básicos

Produtor: publica a tarefa (payload + metadados: idempotency key, prioridade, deadline).
Fila/top: tampão/logs de tarefas.
Worker: pega na tarefa, processa, confirma (ack) ou devolve com erro.
Visibility Timeout/Lease: «alugar» tarefas durante o processamento, e depois, um raro automóvel.
DLQ (Dead Letter Queue): «enterrar» tarefas após o limite de tentativas/erros fatais.
Rate Limit/Concurrency: restrições ao consumo per-worker/para-fila/para-tenente.

• Pull: Ele mesmo pede a tarefa (dosando a carga).
• Push: corretor pega; Preciso de protecção contra o preenchimento dos ladrões fracos.

3) Semânticos de entrega e confirmação

At-matt-once: sem retais; mais rápido, mas pode haver perda.
At-least-once (default para a maioria das filas): pode duplicar → precisa de idempotação do processador.
Effectively exactly-once: é alcançado ao nível da aplicação (Idempotidade, Deadup Stor, Transações/Outbox). Um corretor pode ajudar, mas não uma bala mágica.

• Ack/Nack: um resultado claro.
• Requeue/Retry: с backoff + jitter.
• Mensagem Poison: Envio para DLQ.

4) Equilíbrio e planejamento

4. 1 Prioridade e algoritmos

FIFO: Simples e previsto.
Priority Queue: classes prioritárias (P0... P3).
WRR/WSR (Weighted Round-Robin/Random): proporções de CPU/cereja entre as classes.
WFQ/DRR (equivalente a filas «justas» nas redes): participações per-tenante/cliente.
Deadline/EDF: para tarefas com deadline.
Fair Share: restrição de «vizinhos ruidosos» (per-tenant cotas).

4. 2 Fluxos de processamento

Single-flight/Coalescing: junte a duplicação da tarefa por chave.
Concurrency caps: limites rígidos de paralelismo por tipo de tarefa/integração (API externa).

4. 3 Geo e charding

Chardes por chave (tenant/id) → localidade de dados, ordem estável dentro das barras.
Sticky em dinheiro/recursos: hash routing para workers com estado «colado».

5) Retraias, backoff e DLQ

Backoff exponencial + jitter: 'base 2 ^ attempt'.
Máximo de tentativas e deadline compartilhado (time-to-die) para a tarefa.
Classificação de erros: 'retryable' (rede/limite), 'não-retryable' (validação/proibição de negócios).
Estacionamento/Delay Queue: tarefas adiadas (por exemplo, repetir em 15 min).
Política DLQ: especifique onde e em que condições a mensagem «venenosa» chega; preveja o reprocessor.

6) Idempotidade e dedução

• seen → skip/merge/result-cache.
• Natural keys: Use 'order _ id/payment _ id' em vez de UUID aleatório.
• Outbox: gravação de uma tarefa e seu status em uma transação de base de dados com uma transação de negócios.
• Exactly-once em sink: 'UPSERT' por chave, verificação de versões, 'at-least-once' na fila + idempotidade no banco de dados.

7) Multi-tenência e classes SLA

Divida as filas/striptease por classe: «critical», «padrão», «bulk».
Quotas e prioridades per-tenante (Gold/Silver/Bronze).
Isolamento: dedicate-pool de worker sob P0; segundo plano - em um cluster/nó separado.
Adesion control: Não aceitar mais do que você pode processar em deadline.

8) Skeiling automático

Métricas para skeiling: queue depth, arrival rate, processing time, SLA-deadline.
KEDA/Horizontal Pod Autoscaler: desencadeadores de profundidade SQS/Rabbit/Kafka lag.
Os fatores de contenção são APIs externas rate limits, banco de dados (não destruir backand).

9) Opções tecnológicas e pattern

9. 1 RabbitMQ/AMQP

Exchanges: direct/topic/fanout; Queues с ack/ttl/DLQ (dead-letter exchange).
O Prefetch (QoS) regula «quantas tarefas existem no work».

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.failed x-message-ttl=60000

9. 2 SQS (e similares)

Visibility Timeout, DelaySeconds, RedrivePolicy (DLQ).
Idempotidade - no aplicativo (tabela de dedução).
Limites: batch 1-10 mensagens; Orientem-se para sinos idempotentes.

9. 3 Kafka/NATS JetStream

Para pipas em larga escala: alta largura de banda, retino/réplica.
Fila de Task acima dos logs: uma tarefa = uma mensagem; controle «um worker por chave» através da partitinização/subject.
Retraí: topics individuais/subject-sufixos com backoff.

9. 4 filas Redis (Sidekiq/Resque/Bull/Celery-Redis)

Latidão muito baixa; acompanhe a sustentabilidade (RDB/AOF), as chaves retry e lock-keys para o single-flight.
Adequado para tarefas «fáceis», não para retenção de longo prazo.

9. 5 Quadros

Celery (Python), Sidekiq (Ruby), RQ/BullMQ (Node), Huey/Resque - Retraias prontas, agendamentos, middleware, métricas.

10) Esquemas de rotação e equilíbrio

Round-Robin: Uniforme, mas não considera o peso das tarefas.
Weighted RR - Distribuição por capacidade de worker/pool.
Fair/Backpressure-aware: O worker só tira uma nova tarefa quando estiver pronto.
Priority lanes: filas individuais para a sala de aula; os workers lêem na ordem [P0→... →Pn] quando estão disponíveis.
Hash-routing: 'hash (key)% shards' - para o processamento em caixa.

11) Times, deadline e SLA

Per-task timeout: «aluguel» interno de trabalho (em código de worker) ≤ Visibility Timeout corretor.
Global deadline: A tarefa não faz sentido depois do tempo T - NACK→DLQ.
Budet-aware: reduza o trabalho (brownout) quando o deadline se aproxima (resultados parciais).

12) Observabilidade e controle

12. 1 Métricas

`queue_depth`, `arrival_rate`, `service_rate`, `lag` (Kafka), `invisible_messages` (SQS).
`success/failed/retired_total`, `retry_attempts`, `dlq_in_total`, `processing_time_ms{p50,p95,p99}`.
`idempotency_hit_rate`, `dedup_drops_total`, `poison_total`.

12. 2 Logi/trailing

Correlação: 'job _ id', 'correlation _ id', chave de dedução.
Assinale 'retry/backoff/dlq' como eventos; link com span da consulta original.

12. 3 Dashboards/alerts

Triggers: profundidade> X, p99> SLO, altura do DLQ, tarefas «encolhidas» (visibility> N), chaves «quentes».

13) Segurança e conformidade

Isolar locatários: filas individuais/espaço-chave, LCA, quotas.
Criptografia no transporte e/ou em paz.
Minimização PII em payload; hash/ID em vez de PII bruto.
Segredos: não colocar tokens em tarefas corporais, usar vault/refs.

14) Anti-pattern

Retraias sem idempotação → operações duplas/dinheiro «duas vezes».
Uma fila gigante para tudo → sem isolamento, atrasos imprevisíveis.
Retraias infinitas sem DLQ → tarefas eternas «venenosas».
Visibility Timeout <tempo de processamento → duplicação em cascata.
Grandes payload na fila → pressiona rede/memória; é melhor armazenar no estoque de objetos e passar o link.
O modelo de pool sem backpressure → os workers afundam-se.
Mistura tarefas críticas e bulk em uma única bala de workers.

15) Folha de cheque de implementação

• Classifique as tarefas por SLA (P0/P1/P2) e volume.
• Selecione um corretor/quadro com a semântica e retino desejados.
• Projete chaves, prioridades e rotação (hash/shards/priority lanes).
• Inclua retraí com backoff + jitter e política DLQ.
• Execute a idempotação (chaves, upsert, depor com TTL).
• Configure os temporizadores: per-task, visibilidade, deadline compartilhado.
• Limite a concurrency e rate por integração/tenentes.
• Skeiling automático em profundidade/laje com fusíveis.
• Métricas/trailing/alertas; runbooks para «tempestade» e congestionamento de DLQ.
• Testes de feeling: queda do worker, mensagem «venenosa», sobrecarga, tarefas longas.

16) Exemplos de configuração e código

16. 1 Celery (Redis/Rabbit) - flow básico

python app = Celery("jobs", broker="amqp://...", backend="redis://...")
app.conf.task_acks_late = True        # ack после выполнения app.conf.broker_transport_options = {"visibility_timeout": 3600}
app.conf.task_default_retry_delay = 5 app.conf.task_time_limit = 300        # hard timeout

@app.task(bind=True, autoretry_for=(Exception,), retry_backoff=True, retry_jitter=True, max_retries=6)
def process_order(self, order_id):
if seen(order_id): return "ok"      # идемпотентность do_work(order_id)
mark_seen(order_id)
return "ok"

16. 2 RabbitMQ — DLQ/TTL

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.dlq x-message-ttl=600000   # 10 минут x-max-priority=10

16. 3 Kafka - Retraias em níveis

orders -> orders.retry.5s -> orders.retry.1m -> orders.dlq

(Transfira para entrega adiada por scheduler/cron-consumer.)

16. 4 NATS JetStream — consumer с backoff

bash nats consumer add JOBS WORKERS --filter "jobs.email" \
--deliver pull --ack explicit --max-deliver 6 \
--backoff "1s,5s,30s,2m,5m"

17) FAQ

Q: Quando escolher push contra pull?
A: Pull dá um equilíbrio natural de backpressure e «honesto»; push é mais fácil a baixas velocidades e quando você precisa de TTFB mínimo, mas requer limitadores.

Como evitar a chave quente?
A: Use a chave composta ('order _ id% N'), tampão e processamento batch, digite limites per-chave.

Q: É possível «exactly-once»?
A: Praticamente, através da idempotidade e do outbox transacional. Um exactly-once totalmente «matemático» em todo o caminho é raramente alcançável e caro.

Onde armazenar um grande investimento de tarefas?
A: Armazenamento de objeto (S3/GCS) e, na tarefa, link/ID; reduz a pressão sobre o corretor e a rede.

Q: Como escolher o TTL/visibilidade?
A: Visibility p99 tempo de processamento x reserva 2-3 x. tarefas TTL - menos deadline empresarial.

18) Resultado

Um sistema forte de filas é o equilíbrio entre semânticas de entrega, prioridades e limitadores. Projete chaves e roteiros, forneça idempotidade, retraí com backoff e DLQ, distribua recursos em classes SLA e siga as métricas. Então os seus processos de fundo serão previsíveis, sustentáveis e escaláveis - sem surpresas sob os picos.