Code di messaggi: RabbitMQ, Kafka

Code di messaggi: RabbitMQ, Kafka

1) Quando scegliere cosa

RabbitMQ (AMQP 0-9-1 / 1. 0, classiche code, Quorum Queues, Streams)

Adatto per: RPC/comandi, workflow, attività brevi, instradamento fanout/topic, conferme flessibili, gestione delle priorità.
Pro: una ricca semantica di routing (exchanges), 'basic. qos '(prefetch), per-messaggistica TTL/delay, comode pattern RPC (reply-to), avvio facile.
Contro: cronologia memorizzata in coda, ridimensionamento orizzontale in code/schiarite; Throughput elevato a flussi molto elevati.

Apache Kafka (cronologia eventi, partenze, consumer groups)

Adatto per flussi di eventi, verifiche, event surcing, ETL/integrazioni (Connect), RPS/MBps elevati, repliche/re-processing, strim-processing (Streams/ksqlDB).
I vantaggi sono la cronologia a lungo termine, la scalabilità delle partenze, la replica sostenibile, la compatta delle chiavi.
Contro: il modello pull + partition non è per RPC di piccole dimensioni; Ordine solo all'interno della partitura; la gestione degli schemi/compatibilità è un dovere del comando.

2) Semantici di consegna e invarianti

At-just-once: senza retrai; veloce, rischio di perdita.
At-least-once: con i retrai; richiede idipotenza del consumatore.
Exactly-once: raggiungibile in condizioni limitate (Kafka TX + Idampotent Vendor + coerente sink; RabbitMQ - attraverso la tabella di deduplicazione/chiavi idempotate).
Ordine: RabbitMQ - Ordine della coda (può essere interrotto in caso di retro/multi-consumatori); Kafka è l'ordine della partitura, la chiave imposta il partigiano.

Invarianti di dominio: denaro/bilanci - tramite registri/saghe e comandi idimpotenti; Non fare affidamento su LWW.

3) Modelli di integrazione

Outbox/InBox: la registrazione atomica di un evento in un database → la pubblicazione in coda (outbox) e il consumo idipotente con il login di guadagno (inbox).
DLQ - Dopo n tentativi/errori, in DLQ + alert.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry topic con backoff.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; Kafka è raro, solo special pattern.
Compensi: saghe di eventi; Ogni operazione è inversa.

4) Progettazione di chiavi e topologie

RabbitMQ

Exchanges: `direct`, `topic`, `fanout`, `headers`.
Routing key - Determina l'ingresso in coda (e). Le code sono separate per la priorità.
QoS: 'prefetch' (ad esempio 50-300) bilancia velocità/latitanza.
Quorum Queues: code replicabili per Raft; sostituzione mirrored classic.
Streams: flusso offset (Kafka-simile) per high-throughput/replica.

Kafka

Topic → partition: pianifica «# partition» in base al throughput target e al parallelismo (di nuovo compatibilmente più semplice da ingrandire che da ridurre).
Key: tutte le voci della stessa chiave sono in una singola partitura (garanzia ordine su chiave).
Replication factor: 3 per i temi produttivi, 'min. insync. replica = 2 '+' acks = all 'per l'affidabilità.
Retention in termini di tempo/dimensione compaction - Memorizza gli ultimi valori della chiave + tombstones da eliminare.

5) Retrai, DLQ, idempotenza

RabbitMQ

Ripetizioni: per-messaggistica TTL + DLX (dead-letter exchange) con backoff (ad esempio 1m-5m-15m).
Idampotenza: 'correlation _ id '/' messaggistica-id' + tabella messaggi elaborati (TTL) o comandi definiti.
Conferma manual'basic. ack'dopo la transazione riuscita; 'basic'. nack(requeue=false)` в DLQ.

Kafka

Ripetizioni: retry-topic separati consumer commit offset dopo successo side-effect.
Exactly-once processing (EOS): Producer `enable. idempotence = true ', transazioni producer/consumer,' read _ committed'sul consumatore; sink (ad esempio, Kafka→Kafka o Kafka→DB attraverso una transazione) - Sincronizza attentamente.
Deadup: chiave/Idempotent sul lato della base o compacted topic.

6) Prestazioni e dimensioni

La legge Little: 'L = © x W'

Per i worker, il parallelismo'N d'arrivale _ rate x avg _ processing _ time x riserva (1. 2–1. 5)`.
RabbitMQ prefetch: inizia con «prefetch = 100» e misura r99/tempo «in-flight».
Kafka partition: calcolo dal parallelismo desiderato e obiettivo throughput (ad esempio, 1 partitura stabile 5-20 MB/s per SSD/10GbE).

7) Osservabilità e alert

• Lag/Backlog (messaggi/byte), age messaggi (p95/p99), errato-rate guadagno, DLQ-rate.
• Ora «publikatsiya→obrabotka» (end-to-end).
• La mappa delle dipendenze è un venditore, un broker.

• Connessioni, canali, messaggi non-acked, «memory _ alarm», «disk _ free _ limit», «queue length» p95.
• Report Quorum (leader, Raft log, errori dì 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) Sicurezza e multi-tenenza

Crittografia TLS in-transit, autenticazione (SASL/PLAIN/SCRAM/OAuth, mTLS).
Autorizzazione: vhost/permessi (RabbitMQ), ACL su topic/gruppi (Kafka).
Quote: per connessioni, canali, dimensione coda/punta, velocità di pubblicazione/lettura.
Isolamento per ambienti (uv/stage/prod) e namespace/vhost.

9) Utilizzo e tuning

RabbitMQ

Espandi gli exchanges/queues in base ai nodi (capacito CPU/IO).
Lazy queues per buffer di grandi dimensioni Evitate le code bollenti senza sharding.
Quorum Queues per HA; pianificare le dimensioni del registro raft e del disco.
Criteri TTL/length-limit, priority code solo in caso di effettiva necessità (costosa).

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

Kafka

SSD/NVME, reti rapide Sintonizzatore OS (swapp© basso, limiti di file).
`acks=all`, `linger. ms '(batch),' compressione. type = zstd '/lz4 per la larghezza di banda.
Impostazioni del consumatore: 'max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retention e compettion - Bilanciamento dello storage/replica.

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

10) Integrazione e ecosistema

Kafka Connect (Sinks/Source), Schema Registry (Avro/JSON/Protobuf) e compatibilità ('BACKWARD/FORWARD/FULL').
Kafka Streams/ksqlDB: operazioni stateful, finestre, unità.
RabbitMQ Shovel/Federation - Trasferimento tra cluster/centri.
Operatori K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; Manifesti GitOps.

11) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Definisci use'case'comandi/taschi (RabbitMQ), eventi/verifiche (Kafka).
Seleziona le chiavi («routing key »/« partition key») e imposta «SLO».
Criteri di protezione di base (TLS, ACL), quote, DLQ/TTL.

11-25 giorni

Implementare outbox/inbox, idampotenza e deducibilità.
Configura i retrai con backoff (Rabbit: TTL + DLX; Kafka: retry topics).
Dashboard: lag, age, DLQ-rate, end-to-end latency; Gli alert.

26-45 giorni

Sintonizzatore di banda prefetch/acks (Rabbit); partitions/acks/batch (Kafka).
Procedure DR (mirroring/replica), test di guasto dei nodi.
Documentare i contratti eventi (schemi) e i criteri di compatibilità.

12) Anti-pattern

Uno strumento «universale» per tutte le attività.
Nessun DLQ/TTL: avvelenatori perpetui (poison messaggi).
«Prefetch» illimitato, fame dei consumatori, crescita p99.
Kafka senza chiavi è la perdita di ordine/partenze hot predefinita.
Exactly-once senza un vero bisogno/disciplina è un falso senso di sicurezza.
Segreti/login nel codice, senza TLS/ACL.
Hardcode di diagrammi/versioni di messaggi senza Registry e migrazioni.

13) Metriche di maturità

Lag/age SLO è in esecuzione per il 99% del tempo; DLQ-rate sotto controllo.
Idampotenza copre il 100% dei percorsi critici; outbox/inbox incorporato.
Retention/compettion sono documentati, le repliche non compromettono i consumatori.
Gli alert per ISR/URP (Kafka) e Raft/Limiti di disco (Rabbit) sono configurati.
I contratti di evento sono versionati (Schema Registry) e la compatibilità viene testata in CI.
Game-days regolari: guasto del sito/broker/AZ, verifica del ripristino.

14) Esempi di configure (riepilogo)

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) Conclusione

RabbitMQ e Kafka affrontano diverse classi di attività, come i comandi/taschi e la ricca routing contro il registro degli eventi a lungo termine e lo streaming scalabile. Il successo è nelle semantiche di consegna corrette, nella disciplina dell'idampotenza, nella chiave elaborata, nei retrai/DLQ, nella sorveglianza e nella sicurezza rigorosa. Costruisci una pratica di ingegneria attorno alle code - outbox/inbox, schemi e GitOps - e la tua integrazione diventerà prevedibile, scalabile e sostenibile.