Quando dichiarare/associare code e scambi con RabbitMQ

Question

Abbiamo una libreria wrapper attorno a RabbitMQ sul mio posto di lavoro, creata da qualcuno che non lavora più qui. Sto progettando un nuovo sistema utilizzando Rabbit e sto elaborando l'approccio migliore per la dichiarazione di code, scambi e associazioni. La nostra architettura Rabbit ha alcune zone globali federate e ogni zona ha più nodi Rabbit.

Il codice wrapper per pubblicare messaggi e iscriversi alle code riafferma ogni volta gli scambi, le code e le associazioni pertinenti. La mia preoccupazione è che questo possa introdurre una significativa latenza in ogni messaggio di pubblicazione, specialmente se è necessario attendere la conferma che la coda/lo scambio esista nelle zone globali remote. Mi aspetto che il benchmark di milioni di messaggi al secondo non ripeterà lo scambio per ogni pubblicazione.

In breve, questo approccio mi sembra un po 'dispendioso e paranoico, ma forse mi manca qualcosa.

Così ho alcune domande:

• è ri-dichiarando le code e scambia un significativo calo di prestazioni, dato federazione mondiale?
• È una nuova dichiarazione su ogni utilizzo un buon approccio perché gestisce le code/gli scambi che scompaiono a causa di riavvii del broker o cancellazione esplicita?
• Dovremmo semplicemente dichiarare code e scambi una volta per processo e aspettarci che durino per tutta la vita?
• Gli scambi e le code durevoli devono essere dichiarati in Coniglio config e non dichiarati dalle applicazioni?
• Come devono essere gestite le modifiche di configurazione per code/scambi se le applicazioni continuano a dichiararle con la configurazione precedente? Le applicazioni dovrebbero gestire solo la dichiarazione di fallimento e continuare a pubblicare/consumare?

Answer 1

è ri-dichiarando le code e gli scambi una performance significativa ha colpito

può essere per un grande volume di messaggi

è ri-dichiarando su ogni utilizzare un buon approccio perché gestisce code/scambi che scompaiono a causa di riavvii del broker o cancellazione esplicita?

"buon approccio" - no.

"efficace" nel prevenire scomparse scambi/code/bindings arrechi fastidio, sì ... ma non è una buona cosa da fare, nella maggior parte dei casi

(forse ok se si invia solo un messaggio molto di rado c'è un vero motivo di preoccupazione per la topologia che viene cancellata)

Dovremmo semplicemente dichiarare code e scambi una volta per processo e aspettarci che durino per tutta la vita?

questo è il mio approccio generale.

apre la possibilità che la topologia venga distrutta e tu non lo sai. dipende se pensi che questo accadrà davvero.

Gli scambi e le code durevoli devono essere dichiarati in Coniglio config e non dichiarati dalle applicazioni?

non c'è niente di sbagliato nella topologia predefinita, ma manca moltissimo della potenza e della flessibilità di rabbitmq e del protocollo amqp.

molti sistemi di messaggistica richiedono topologie predefinite e strumenti specializzati per la gestione della topologia. amqp è abbastanza diverso in quanto consente di definire la topologia secondo necessità.

se avete a che fare con una topologia statica, allora questo potrebbe essere una buona opzione per voi

Come dovrebbe config modifiche per le code/scambi essere trattati se le applicazioni possono continuare a dichiararli con il vecchio config? Le applicazioni dovrebbero gestire solo la dichiarazione di fallimento e continuare a pubblicare/consumare?

farei crash dell'applicazione e segnalarlo tramite qualsiasi meccanismo di segnalazione degli errori che si sta utilizzando.

avere un cambio di topologia è di solito qualcosa di importante e fatto per un motivo. se la dichiarazione di scambio o di coda deve cambiare, probabilmente c'è una buona ragione e il codice non dovrebbe continuare con la vecchia dichiarazione.