Progettazione di un'architettura di coda dei messaggi scalabile

Di recente ho iniziato a studiare le sfumature dell'architettura informatica scalabile e aziendale e uno dei componenti centrali è una coda di messaggistica. Per apprendere il massimo da qualsiasi paradigma di programmazione, sto cercando di implementare la mia versione di un servizio di coda di messaggistica.

Finora, il mio progetto iniziale viene eseguito su un listener socket threaded, ma per impedire che lo stesso messaggio venga scaricato due volte da due nodi di elaborazione separati, il registro dell'indice della coda dei messaggi viene bloccato quando viene avviata una lettura e sbloccato dopo che il registro è stato aggiornato. In quanto tale, ciò nega la necessità di essere threadato e significa che esiste un limite per le dimensioni di un sistema scalabile basato sulla velocità di elaborazione del server su cui è in esecuzione il servizio di coda di messaggistica.

Il modo per aggirare il problema sarebbe eseguire il servizio di coda messaggi su più server, ma ciò aumenterà la probabilità che lo stesso messaggio venga scaricato due volte. L'unico modo per evitare che si verifichino tali problemi sarebbe quello di includere un callback di revoca che (dopo che i server, o anche i thread su un singolo server, hanno sincronizzato le loro informazioni e rilevato tale riemissione) avrebbe comandato al nodo di elaborazione di interrompere la sua lavoro corrente e interrogare nuovamente la coda dei messaggi per il messaggio successivo, ma di nuovo, ci sarebbe un limite massimo in cui la maggior parte del traffico inviato sarebbe sincronizzazioni e richiamate di revoca, causando un collo di bottiglia e rallentando l'elaborazione delle informazioni in modo che un molti dei nodi di elaborazione eseguono operazioni null e perdono tempo.

L'ultimo modo in cui riesco a risolvere questo problema è avere ogni server della coda dei messaggi (e ogni thread su ciascun server) avrebbe uno scostamento specifico su dove si trova nella coda, ma ciò potrebbe avere problemi basati sul tipo di applicazione, soprattutto se l'elaborazione deve essere eseguita in un ordine specifico.

Quindi, tutto ciò che viene detto, ci sono progetti di architettura delle code dei messaggi che potrebbero mostrarmi come i servizi esistenti di coda dei messaggi di livello aziendale evitano questi problemi?

In breve:

Questo è un problema difficile Non reinventare la ruota.

Esistono molte tecnologie che risolvono il livello della coda dei messaggi. Loro includono

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, con BLPOP o PUBSUB (ho chiesto come farlo qui ).
• Altre implementazioni AMQP oltre a RabbitMQ

Penso che sia fuori discussione per me discutere gli svantaggi di ciascuno, non ultimo perché non rivendico davvero l'esperienza di fare questa tosse bene non usare la tosse di coniglio .

Anche se non vuoi usare nessuna di queste tecnologie, leggi le loro documentazioni.

Questo ti insegnerà sui modelli di progettazione che sono possibili su un sistema. La lettura della documentazione di ZeroMQ ti istruirà su molte architetture classiche di accodamento dei messaggi che hanno gentilmente implementato. Anche se non usi ZeroMQ, conoscere questi schemi ti aiuterà a valutare altre tecnologie di accodamento chiedendoti se puoi implementare quel modello lì.

Informazioni sul modello di coda di scambio di RabbitMQ / AMQP. Il routing potrebbe venire per te - questo è supportato da Redis PUBSUB ma non ricordo di essere supportato da ZeroMQ - e le dissolvenze sono qualcosa che il mio negozio ha usato, anche se mal implementato su un sondaggio Memcached (yuck!), Per un po 'di tempo .

Come sceglierne uno?

Lavoro in una startup il cui SLA è tipico per un'app Web - alcune interruzioni vanno bene, purché possiamo ripristinare rapidamente il servizio con una piccola perdita di dati. Non abbiamo dovuto pensare a problemi di ridimensionamento come Twitter o Tumblr, quindi non abbiamo davvero dovuto pensare al volume di throughput. Detto questo, se stai implementando uno SLA simile al mio, mi verranno in mente queste considerazioni:

• funzionano davvero le librerie client ? È facile mantenere una connessione in essi? (ZeroMQ, Redis: sì. RabbitMQ: no).
• il monitoraggio e la gestione sono facili da una console server? (Redis: sì, RabbitMQ: sì, ZeroMQ: non che io ricordi, ma non l'abbiamo usato così a lungo)
• i client supportano le code interne in modo che si verifichino piccole perdite di dati in caso di interruzioni brevi? (ZeroMQ, Redis: sì. RabbitMQ: no.)

Naturalmente se lavori per un negozio di trading ad alta frequenza, queste saranno le tue preoccupazioni minori. Sarai più disposto a dedicare tempo allo sviluppo in una libreria lato client in cambio di una maggiore produttività alla fine. Ma scrivo di più per avvertirti che queste tecnologie tendono a commercializzare sulla base delle loro prestazioni, non della loro funzionalità pronta all'uso. Se sei un web-startup, sei molto più interessato a quest'ultimo che al primo e, di conseguenza, qualcosa come Redis, che è più ottimizzato per facilità d'uso a buone prestazioni che difficoltà d'uso a grandi prestazioni, è probabilmente un scelta migliore di RabbitMQ. (Non mi piace davvero RabbitMQ).