Perché non trasmettere semplicemente il messaggio a tutti i nodi e poi lasciare che i nodi scelgano i messaggi che vogliono inoltrare tramite WebSockets ai client?
Se hai molto di messaggi (tanto che l'impatto sulla rete diventa evidente), usare l'ID utente nella chiave di routing potrebbe essere il modo più semplice per ridurre il traffico tra MQS e i nodi.
Immagina di avere un'applicazione di chat con stanze e utenti. Utilizzando uno scambio di argomenti , puoi utilizzare le chiavi di routing come chat.room123.user456 quando trasmetti un messaggio di utente 456 pubblicato nella stanza 123. Puoi consumare quei messaggi avendo una coda con una chiave di associazione chat.room123.* , che ascolterà tutti i messaggi in una stanza specifica. Potresti anche voler consumare i messaggi inviati da un utente specifico, indipendentemente dalla stanza, utilizzando la chiave di associazione chat.*.user456 . Per ridimensionarlo, potresti avere alcuni server che gestiscono alcune stanze e altri server che gestiscono alcuni utenti. Ad esempio, un determinato server può avere connessioni WebSockets per gli utenti 17, 41 e 48 e avere le chiavi di associazione chat.*.user17 , chat.*.user41 e chat.*.user48 .
La parte difficile qui potrebbe essere la gestione del caso in cui la connessione WebSockets viene interrotta e il client si riconnette a un nodo diverso. Le sessioni persistenti potrebbero risolvere questo problema. A parte questo, la gestione degli errori e la perdita della connessione WebSockets non è diversa da qualsiasi altro scenario in cui i messaggi da un servizio di raccolta messaggi dovrebbero essere preelaborati e inviati a una terza parte.