Filas de mensagens: RabbitMQ, Kafka

Filas de mensagens: RabbitMQ, Kafka

1) Quando escolher

RabbitMQ (AMQP 0-9-1 / 1. 0, filas clássicas, Quorum Queues, Streams)

Adequado para RPC/comandos, workflow, tarefas curtas, funout/topic rotation, confirmações flexíveis, gerenciamento de prioridades.
Benefícios: rica semântica de rotação (exchanges), 'basic. qos '(prefetch), per-mensagem TTL/delay, pattern RPC (reply-to) confortáveis, início fácil.
Contras: histórico armazenado na fila, escala horizontal em filas/chardes; Alto custo Throughput com fluxos muito grandes.

Apache Kafka (logs de eventos, partitações, consumer groups)

Adequado para: fluxo de eventos, auditoria, event surcing, ETL/integrações (Connect), RPS alto/MBps, replay/re-processamento, processamento de strim (Streams/ksqlDB).
Vantagens: registro de longa duração, zoom em partituras, réplicas sustentáveis, compactação de chaves.
Contras: O modelo «pull + partição» não é para RPC pequeno; ordem apenas dentro da partição; gerenciamento de esquemas/compatibilidade é obrigação do comando.

2) Semânticos de entrega e invariantes

At-matt-once: sem retais; rápido, risco de perda.
At-least-once: com retais; exige idepotência do consumidor.
Exactly-once: alcançável em condições limitadas (Kafka TX + idumpotente de produção + sink alinhado; RabbitMQ - através da tabela de dedução/chaves idumpotentes).
Ordem: RabbitMQ - ordem da fila (pode ser perturbado por retais/multi-consumers); Kafka - ordem na partição, a chave define a partição.

Invariantes de domínio: dinheiro/balanço - por meio de revistas/sagas e comandos idempotantes; Não confiem na LWW.

3) Patrões de integração

Outbox/InBox: Gravação atômica de evento em BD → publicação em fila (outbox) e consumo idumpotente com registo de ganho (inbox).
DLQ (cartas mortas): após N tentativas/erros - em DLQ + alert.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry-topics com backoff.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; Os Kafka são raros, apenas os patterns.
Compensações: sagas sobre eventos; Cada operação tem o inverso.

4) Design de chaves e topologias

RabbitMQ

Exchanges: `direct`, `topic`, `fanout`, `headers`.
Roting key: determina a entrada na fila (e). Para priorizar, há filas individuais.
QoS: 'prefetch' (por exemplo, 50-300) equilibra velocidade/latência.
Quorum Queues: filas replicáveis para Raft; substituir mirrored classic.
Streams: fluxo com offsets (Kafka-como) para high-throughput/replay.

Kafka

Topic → partition: Planeje '# partition' com base no throughput e paralelismo de destino (de volta, é mais fácil aumentar do que reduzir).
Key: todos os registros da mesma chave estão na mesma partição (garantia de ordem da chave).
Replicação fator: 3 para temas produtivos, 'min. insync. replicas = 2 '+' acks = all 'para confiabilidade.
Retenção: em tempo/tamanho; competition - armazena os últimos valores da chave + tombstones para remoção.

5) Retrai, DLQ, Idempotação

RabbitMQ

Repetições: per-mensagem TTL + DLX (dead-letter exchange) com backoff (por exemplo, 1m → 5m → 15m).
Idempotidade: 'correlation _ id '/' mensagem-id' + tabela de mensagens processadas (TTL) ou comandos definidos.
Confirmações: manual 'basic. ack 'após uma transação bem sucedida;' basic. nack(requeue=false)` в DLQ.

Kafka

Repetições: retry-topics individuais; consumer uma comitiva off-set após o sucesso do side-effect.
Exactly-once processing (EOS): Producer `enable. idempotence = true ', produções transacionadas/consumer,' read _ committed 'no consumidor; sink (por exemplo, Kafka→Kafka ou Kafka→DB através de transação) - Sincronizar com cuidado.
Por chave/idumpotente no lado da base, ou por compacted topic.

6) Desempenho e dimensão

Lei Little: 'L = £ x W'

Workers: paralelismo necessário 'N ≈ arrival _ rate x avg _ processing _ time x reserva (1. 2–1. 5)`.
Prefetch: comece com 'prefetch = 100' e mede p99/hora 'in-flight'.
Kafka partition: cálculo a partir do paralelismo de consumo desejado e do objetivo de throughput (por exemplo, 1 partição é estável 5-20 MB/s por SSD/10GbE).

7) Observabilidade e alertas

• Lag/Backlog (mensagens/bytes), age mensagens (p95/p99), erro-rate salário, DLQ-rate.
• Hora «publikatsiya→obrabotka» (end-to-end).
• Cartão de Dependências: Produtor → Corretor → Conselheiro.

• Ligações, canais, mensagens não-acked, 'memory _ alarm', 'disk _ free _ limit', 'queue length' p95.
• Relatórios de Quorum (líder, raft, falhas 'quorum not enough').

• Under-replicated partitions, ISR shrink/expand, controller changes.
• Producer errors (timeouts, `request latency`), consumer lag per group/partition.
• Broker I/O, page cache hit, GC, ZooKeeper/KRaft health.

8) Segurança e multi-tenência

Criptografia TLS in-transit, autenticação (SASL/PLAIN/SCRAM/OAuth, mTLS).
Permissão: vhost/permissões (RabbitMQ), LCA em top/grupo (Kafka).
Quotas: por conexões, canais, tamanho da fila/topo, velocidade de publicação/leitura.
Isolamento de quarta-feira (dave/estágio/prod) e namespace/vhost.

9) Exploração e sintonização

RabbitMQ

Espalhe os exchanges/queues em nódulos (capacidade CPU/IO).
Lazy queues (mensagens de disco) para buffers grandes; Evite filas quentes sem charding.
Quorum Queues para HA; planeje o tamanho do registro Raft e o disco.
Políticas de TTL/length-limit, priority filas apenas em caso de necessidade real (caro).

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

Kafka

SSD/NVME, redes rápidas; Sintonizar OS (swappiness baixo, limites de arquivo).
`acks=all`, `linger. ms '(batidão),' compressão. tipo = zstd '/lz4 para saída de banda.
Parâmetros do consumidor: 'max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retenção e competition - equilíbrio de armazenamento/réplica.

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10) Integração e ecossistema

Kafka Connect (Sinks/Surces), Schema Registry (Avro/JSON/Protobuf) e compatibilidade ('BACKWARD/FORWARD/FULL').
Kafka Streams/ksqlDB: Operações stateful, janelas, máquinas.
RabbitMQ Shovel/Federation: transferência entre clusters/centros.
Operadores K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; Manifestos GitOps.

11) Folha de cheque de implementação (0-45 dias)

0-10 dias

Definir use-case ': comandos/tasca (RabbitMQ), eventos/auditoria (Kafka).
Selecionar as chaves ('roting key '/' partition key') e definir 'publikatsiya→obrabotka' SLO.
Políticas básicas de segurança (TLS, LCA), quotas, DLQ/TTL.

11 a 25 dias

Implementar outbox/inbox, idempotidade e dedução.
Ajustar retraí com backoff (Rabbit: TTL + DLX; Kafka: retry topics).
Dashboards: lag, age, DLQ-rate, end-to-end latency; Alertas.

26-45 dias

Sintonização de largura de banda: prefetch/acks (Rabbit); partitions/acks/batch (Kafka).
Procedimentos de DR. (espelhamento/replicação), testes de falha de nódulos.
Documentar contratos de eventos (esquema) e políticas de compatibilidade.

12) Anti-pattern

Uma ferramenta «universal» para todas as tarefas.
Falta de DLQ/TTL: envenenadores eternos (poison mensagens).
Ilimitado 'prefetch', fome dos consumidores, crescimento p99.
Kafka sem chaves → perda de ordem/partituras quentes padrão.
«Exactly-once» sem necessidade real/disciplina é uma falsa sensação de segurança.
Segredos/logins no código, sem TLS/LCA.
Hardcod circuitos/versões de mensagens sem Registry ou migração.

13) Métricas de maturidade

O Lag/age SLO é executado ≥ 99% do tempo; DLQ-rate sob controle.
A idimpotência cobre 100% das vias críticas; outbox/inbox implantado.
A retenção/competition está documentada, e a réplica não quebra os consumidores.
Os alerts para ISR/URP (Kafka) e Raft/Limite de disco (Rabbit) estão configurados.
Os contratos de eventos são versionizados (Schema Registry) e a compatibilidade é testada na CI.
Game-days regular: falha nó/corretor/AZ, verificação de recuperação.

14) Exemplos de configs (resumo)

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15) Conclusão

RabbitMQ e Kafka lidam com diferentes classes de tarefas, comandos/tascos e rotação rica contra o diário de eventos de longo prazo e o streaming escalável. Sucesso - semânticas de entrega corretas, disciplina de idempotidade, chave elaborada, retais/DLQ, observabilidade e segurança rigorosa. Construa em torno das filas de engenharia - outbox/inbox, esquemas e políticas GitOps - e sua integração será previsível, escalável e sustentável.