Quali sono i pattern di messaggistica RabbitMQ più comuni e quando usarli?

I pattern di messaggistica RabbitMQ determinano se un worker gestisce un job, ogni sottoscrittore riceve un evento o un servizio attende una risposta. Se scegli il pattern sbagliato, il tuo sistema potrebbe duplicare il lavoro, perdere eventi utili o bloccarsi su chiamate che avrebbero dovuto rimanere asincrone.

RabbitMQ ti offre exchange, code, binding, acknowledgment e proprietà dei messaggi. Il lavoro di progettazione utile consiste nello scegliere come questi elementi si adattano alla tua applicazione. I pattern comuni sono Work Queues, Publish/Subscribe, Direct o Topic routing e Request/Reply.

---

Work Queues: Distribuisci i Job tra i Worker

Il pattern Work Queue, spesso chiamato Task Queue, è il pattern di messaggistica più semplice e comune utilizzato per distribuire attività dispendiose in termini di tempo tra più processi worker (consumer).

Come funziona

1. Un Producer invia attività (messaggi) a una singola Coda.
2. Più Consumer (Worker) ascoltano la stessa Coda.
3. RabbitMQ consegna ogni messaggio a un solo consumer, quindi i worker condividono il backlog.

Per impostazione predefinita, RabbitMQ distribuisce i messaggi round-robin tra i consumer attivi. Questa distribuzione non è sempre equa se un worker esegue lavori lenti mentre un altro riceve lavori veloci, quindi di solito si abbina questo pattern con acknowledgment e un limite di prefetch.

Usa gli acknowledgment

Con gli acknowledgment manuali, un worker comunica a RabbitMQ quando un'attività è terminata. Se il worker muore prima di inviare basic_ack, RabbitMQ può riaccodare e consegnare nuovamente quel messaggio a un altro consumer. Questo è ciò che rende una work queue utile per la generazione di report, l'elaborazione di immagini, i job di fatturazione o qualsiasi attività che non vuoi venga persa silenziosamente.

Imposta un prefetch count

basic.qos controlla quanti messaggi non riconosciuti un consumer può trattenere contemporaneamente. Un prefetch_count di 1 è un punto di partenza sicuro per lavori lenti e irregolari, perché RabbitMQ non invierà un secondo job a quel consumer finché non avrà riconosciuto il primo. Per lavori più veloci, puoi aumentare il valore dopo aver misurato la produttività e l'utilizzo della memoria.

Esempio di implementazione (Concettuale)

# Configurazione del consumer per un fair dispatch
channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='task_queue', on_message_callback=worker_function)

# La logica del worker deve inviare un acknowledgment dopo l'elaborazione riuscita
worker_function(ch, method, properties, body):
    # Elabora il task...
    ch.basic_ack(delivery_tag=method.delivery_tag)

Publish/Subscribe: Trasmissione di Eventi

Il pattern Pub/Sub è progettato per trasmettere messaggi a più consumer interessati contemporaneamente. A differenza delle Work Queues, dove ogni messaggio viene consumato da un solo worker, Pub/Sub garantisce che ogni sottoscrittore connesso riceva una copia del messaggio.

Usa un exchange fanout

Un producer pubblica su un exchange fanout. L'exchange ignora le routing key e copia il messaggio in ogni coda ad esso associata. Ogni sottoscrittore ha normalmente la propria coda, quindi un servizio di logging, un servizio di metriche e un servizio di audit possono ricevere lo stesso evento senza competere per esso.

Casi d'uso

• Notifiche in tempo reale: Trasmetti un evento di modalità manutenzione a ogni istanza dell'app.
• Distribuzione dei log: Invia lo stesso evento di log a un servizio di archiviazione e a un servizio di alerting.
• Invalidamento della cache: Dì a tutte le istanze del servizio di cancellare una cache locale dopo una modifica al database.

Suggerimento per l'implementazione

Per sottoscrittori di breve durata, crea una coda esclusiva e auto-eliminante e associala all'exchange fanout. Per sottoscrittori durevoli, usa una coda durevole in modo che il sottoscrittore possa tornare e leggere i messaggi arrivati mentre era offline.

Direct e Topic Routing: Invia Eventi in Modo Selettivo

Mentre l'exchange Fanout fornisce una trasmissione cieca, AMQP offre exchange per la pubblicazione selettiva, estendendo il modello Pub/Sub.

Direct exchange

I messaggi vengono instradati verso le code in base a una corrispondenza esatta tra la routing key del messaggio e la binding key della coda. Questo è utile quando devi indirizzare specificamente diversi tipi di consumer.

Ad esempio, il tuo publisher di log può inviare messaggi con routing key come error, warning e info. Una coda di alerting può essere associata solo a error, mentre una coda di archivio può essere associata a tutte e tre le severità.

Topic exchange

Questo è il tipo di exchange più flessibile, che consente a binding key e routing key di utilizzare wildcard. La routing key viene trattata come un elenco delimitato (ad esempio, utilizzando punti .).

• * corrisponde esattamente a una parola.
• # corrisponde a zero o più parole.

Una routing key come orders.us.created può andare a una coda antifrode associata a orders.*.created e a una coda per le operazioni USA associata a #.us.#. Usa gli exchange topic quando le tue regole di routing sono categorie aziendali reali, non solo un campo fisso.

Request/Reply: Chiedi una Risposta Specifica

Il pattern Request/Reply consente a un'applicazione client di inviare un messaggio di richiesta e attendere in modo sincrono una risposta da un worker (server). Sebbene la messaggistica sia intrinsecamente asincrona, questo pattern simula le tradizionali Remote Procedure Call (RPC) sul bus di messaggistica.

Usa reply_to e correlation_id

1. Il client invia una richiesta a una coda come rpc_queue.
2. Il client imposta reply_to su una coda di callback che sta consumando.
3. Il client imposta un correlation_id univoco.
4. Il worker elabora la richiesta e pubblica la risposta nella coda reply_to.
5. Il client abbina la risposta alla richiesta originale controllando correlation_id.

Casi d'uso

• Ricerca di servizi: Recupera un profilo utente o un feature flag da un altro servizio.
• Decisioni rapide: Controlla l'inventario prima di accettare un ordine.

Usalo con attenzione

Request/Reply è utile, ma reintroduce l'attesa sincrona nel tuo sistema di messaggistica. Imposta timeout lato client, gestisci le risposte duplicate ed evita di usare RPC per job di lunga durata. Per lavori lenti, pubblica un comando, restituisci un ID job e invia eventi di avanzamento o completamento separatamente.

Flusso RPC Concettuale

graph TD
    A[Client (Richiedente)] -->|1. Messaggio di Richiesta (incl. reply_to, correlation_id)| B(Coda Richiesta RPC);
    B --> C[Server (Worker)];
    C -->|2. Elabora Richiesta|
D[Risultato];
    D -->|3. Messaggio di Risposta (tramite reply_to, mantenendo correlation_id)| A;

---

Pattern RabbitMQ Comuni a Colpo d'Occhio

Pattern	Tipo di Exchange	Meccanismo di Routing	Caratteristica Principale	Caso d'Uso Principale
Work Queues	Default o Direct	Una coda condivisa dai worker	Un messaggio, un consumer	Bilanciamento del carico per attività di lunga durata
Publish/Subscribe	Fanout	Ignora la routing key	Un messaggio, tutte le code associate	Trasmissioni di sistema, logging
Direct Routing	Direct	Corrispondenza esatta della routing key	Targeting selettivo dei consumer	Routing basato su severità o tipo
Topic Routing	Topic	Corrispondenza con wildcard (*, #)	Routing flessibile e complesso	Comunicazione tra microservizi, flussi di eventi
Request/Reply (RPC)	Direct (per la risposta)	Usa reply_to e correlation_id	Simula chiamate API sincrone	Ricerche immediate di servizi, piccole transazioni

Conclusione

Inizia dalla forma della comunicazione. Usa Work Queues quando esattamente un worker dovrebbe gestire un job, Pub/Sub quando ogni sottoscrittore dovrebbe vedere un evento, Direct o Topic routing quando solo alcuni sottoscrittori dovrebbero vederlo, e Request/Reply solo quando il chiamante ha veramente bisogno di una risposta immediata.