coldwa.st
All guidesProgrammingWebDataToolsDatabasesHaskellConceptsCabal & buildsToolchainCompilerPerformanceEditor & HLS

Programmazione · Architettura · Backend

Cos’è una coda di messaggi?

Di ColdwastAggiornato il 9 lug 20268 min di lettura#codadimessaggi#architettura#backend
Un nastro trasportatore automatizzato che porta articoli in una fabbrica
Un nastro trasportatore automatizzato che porta articoli in una fabbrica - una coda fa avanzare il lavoro in ordine, un elemento alla volta, proprio come una coda di messaggi.

Quando una parte della tua app deve passare lavoro a un’altra - inviare un’email, ridimensionare un’immagine, addebitare una carta - farlo in linea fa attendere l’utente e lega strettamente le due parti. Una coda di messaggi è la soluzione standard: un buffer nel mezzo dove un servizio deposita un compito e un altro lo preleva più tardi. Questa guida spiega cos’è una coda di messaggi, come la usano producer e consumer, e quando ti serve davvero.

L’idea centrale: producer, coda, consumer

Una coda di messaggi si colloca tra il codice che crea il lavoro e quello che lo esegue. Un producer mette un messaggio - una piccola unità di dati che descrive un compito - nella coda. Un consumer preleva i messaggi e li elabora. La coda conserva ogni messaggio finché non viene gestito, di solito in ordine primo entrato, primo uscito. Il punto chiave: il producer non attende il consumer e non ha nemmeno bisogno di sapere chi sia.

Un nastro trasportatore automatizzato con confezioni di bottiglie d’acqua in una fabbrica
Un nastro trasportatore automatizzato che porta articoli in una fabbrica - una coda fa avanzare il lavoro in ordine, un elemento alla volta, proprio come una coda di messaggi.

Perché usarne una: disaccoppiamento, buffer, resilienza

Una coda offre più cose insieme. Disaccoppia producer e consumer, così li costruisci, distribuisci e scali separatamente. Assorbe i picchi: se arrivano 10.000 iscrizioni in una volta, si mettono in fila invece di sovraccaricare il worker. Aggiunge resilienza, perché se un consumer è giù i messaggi attendono invece di perdersi. E rende il lavoro asincrono - restituisci subito il controllo all’utente e fai la parte lenta in background.

Coda vs pubblicazione/sottoscrizione

Ci sono due schemi comuni. In una semplice coda di lavoro, ogni messaggio è consegnato a esattamente un consumer - ideale per distribuire compiti su un pool di worker. Nella pubblicazione/sottoscrizione (pub/sub), un messaggio è trasmesso a ogni sottoscrittore interessato - ideale per eventi a cui reagiscono più parti del sistema. Molti broker supportano entrambi, con l’idea di exchange o topic per decidere chi riceve una copia.

Una fila di tubi bianchi con misuratori di portata in un collettore industriale
Un collettore di tubi con misuratori di portata - un broker instrada ogni messaggio nel canale giusto, come le valvole dirigono il flusso.

Le garanzie di consegna, onestamente

Le code descrivono quanto si impegnano a consegnare un messaggio: al massimo una volta (veloce, può perdere), almeno una volta (può consegnare due volte) ed esattamente una volta (la più difficile, spesso ridimensionata in pratica). La maggior parte dei sistemi reali offre l’almeno-una-volta, il che significa che i tuoi consumer dovrebbero essere idempotenti - elaborare due volte lo stesso messaggio non deve causare danni. I consumer di solito confermano un messaggio solo dopo averlo finito; se uno va in crash prima della conferma, il messaggio viene riconsegnato. I messaggi che falliscono di continuo finiscono in una coda di messaggi non recapitati per l’ispezione.

Broker comuni: RabbitMQ, Kafka, Redis

Pochi strumenti dominano. RabbitMQ è un broker classico con routing flessibile (parla AMQP). Apache Kafka è un log durevole ad alto throughput: conserva i messaggi così che i consumer possano rigiocare un flusso, il che si adatta a pipeline di eventi e analitica. Redis offre code e stream leggeri e molto veloci, ma meno durevoli per impostazione predefinita. Nel cloud, opzioni gestite come AWS SQS e Google Pub/Sub tolgono il peso operativo. Scegli in base al bisogno: RabbitMQ per il routing, Kafka per flussi rigiocabili ad alto volume, Redis per il semplice e veloce.

Quando non ti serve

Una coda è un pezzo mobile da far girare e monitorare. Se il lavoro è rapido e chi chiama ha davvero bisogno del risultato subito, una chiamata di funzione diretta o una scrittura su database è più semplice. Ricorri a una coda di messaggi quando ti servono job in background asincroni, vuoi assorbire picchi di carico, o devi disaccoppiare servizi che non dovrebbero dipendere direttamente l’uno dall’altro - le stesse ragioni per cui forse metti già i servizi dietro un reverse proxy o un load balancer.

In sintesi

Una coda di messaggi è un buffer tra servizi: i producer depositano lavoro, i consumer lo prelevano, e i due restano disaccoppiati mentre il carico viene livellato. Usa una semplice coda di lavoro per distribuire compiti, il pub/sub per trasmettere eventi, aspettati una consegna almeno-una-volta (rendi quindi idempotenti i consumer), e ricorri a RabbitMQ, Kafka, Redis o una coda cloud gestita quando ti serve un’elaborazione asincrona affidabile.