C'è qualche motivo per usare RabbitMQ su Kafka?

Mi è stato chiesto di valutare RabbitMQ invece di Kafka, ma ho trovato difficile trovare una ragione per cui sta facendo qualcosa di meglio di Kafka. Qualcuno sa se è davvero migliore in termini di produttività, durata, latenza o facilità d'uso?

RabbitMQ è un broker di messaggi solido e generico che supporta diversi protocolli come AMQP, MQTT, STOMP, ecc. Può gestire un throughput elevato. Un caso d'uso comune per RabbitMQ è la gestione di processi in background o attività di lunga durata, come la scansione di file , il ridimensionamento delle immagini o la conversione di PDF. RabbitMQ viene utilizzato anche tra microservizi, dove funge da mezzo di comunicazione tra le applicazioni, evitando colli di bottiglia che passano i messaggi.

Kafka è un bus di messaggi ottimizzato per flussi di dati e riproduzione ad alto ingresso . Usa Kafka quando hai la necessità di spostare una grande quantità di dati, elaborare i dati in tempo reale o analizzare i dati per un periodo di tempo. In altre parole, dove i dati devono essere raccolti, archiviati e gestiti. Un esempio è quando si desidera tenere traccia dell'attività dell'utente in un negozio online e generare articoli suggeriti da acquistare. Un altro esempio è l'analisi dei dati per il monitoraggio, l'ingestione, la registrazione o la sicurezza.

Kafka può essere visto come un broker di messaggi duraturo in cui le applicazioni possono elaborare e rielaborare i dati in streaming su disco. Kafka ha un approccio di routing molto semplice. RabbitMQ ha opzioni migliori se devi indirizzare i tuoi messaggi in modo complesso ai tuoi consumatori. Utilizzare Kafka se è necessario supportare i consumatori batch che potrebbero essere offline o i consumatori che desiderano messaggi a bassa latenza. 

Per capire come leggere i dati da Kafka, dobbiamo prima capire i suoi consumatori e gruppi di consumatori. Le partizioni consentono di parallelizzare un argomento suddividendo i dati su più nodi. Ogni record in una partizione è assegnato e identificato dal suo offset univoco. Questo offset punta al record in una partizione. Nell'ultima versione di Kafka, Kafka mantiene un offset numerico per ogni record in una partizione. Un consumatore in Kafka può commettere automaticamente offset periodicamente oppure può scegliere di controllare manualmente questa posizione impegnata. RabbitMQ manterrà tutti gli stati sui messaggi consumati / riconosciuti / non riconosciuti. Trovo Kafka più complesso da capire rispetto al caso di RabbitMQ, in cui il messaggio viene semplicemente rimosso dalla coda una volta che viene intercettato.

Le code di RabbitMQ sono più veloci quando sono vuote, mentre Kafka conserva grandi quantità di dati con un sovraccarico minimo: Kafka è progettata per contenere e distribuire grandi volumi di messaggi. (Se prevedi di avere code molto lunghe in RabbitMQ, puoi dare un'occhiata alle code pigre .)

Kafka è costruito da zero con in mente il ridimensionamento orizzontale (scala aggiungendo più macchine), mentre RabbitMQ è principalmente progettato per il ridimensionamento verticale (scala aggiungendo più potenza).

RabbitMQ ha un'interfaccia intuitiva integrata che ti consente di monitorare e gestire il tuo server RabbitMQ da un browser web. Tra le altre cose, è possibile gestire code, connessioni, canali, scambi, utenti e autorizzazioni utente: creati, eliminati ed elencati nel browser, è possibile monitorare le tariffe dei messaggi e inviare / ricevere messaggi manualmente. Kafka ha una serie di strumenti open-source, e anche alcuni commerciali una volta , offrendo funzionalità di amministrazione e monitoraggio. Direi che è più facile / veloce ottenere una buona comprensione di RabbitMQ.

Ulteriori letture e alcuni dati di confronto sono disponibili qui: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Raccomandando anche l'articolo di settore: "Kafka contro RabbitMQ: uno studio comparativo di due implementazioni di pubblicazione / sottoscrizione di riferimento del settore": http://dl.acm.org/citation.cfm?id=3093908

Lavoro in un'azienda che fornisce sia Apache Kafka che RabbitMQ come servizio.

Sento questa domanda ogni settimana ... Mentre RabbitMQ (come IBM MQ o JMS o altre soluzioni di messaggistica in generale) viene utilizzato per la messaggistica tradizionale, Apache Kafka viene utilizzato come piattaforma di streaming (messaggistica + archiviazione distribuita + elaborazione dei dati). Entrambi sono progettati per diversi casi d'uso.

Puoi usare Kafka per "messaggistica tradizionale", ma non usare MQ per scenari specifici di Kafka.

L'articolo “ Apache Kafka vs. Enterprise Service Bus (ESB) —Amici, nemici o nemici? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ ) ”spiega perché Kafka non è competitivo ma complementare alle soluzioni di integrazione e messaggistica (incluso RabbitMQ) e come integrarli entrambi.

5 Differenze principali tra Kafka e RabbitMQ, cliente che le utilizza:

Quale sistema di messaggistica scegliere o dovremmo cambiare il nostro sistema di messaggistica esistente?

Non esiste una risposta a questa domanda. Un approccio possibile rivedere quando si deve decidere quale sistema di messaggistica o si dovrebbe cambiare il sistema attuale è quello di “ valutare la portata e il costo ”

Una differenza fondamentale che voi ragazzi avete dimenticato è RabbitMQ è il sistema di messaggistica basato su push mentre Kafka è il sistema di messaggistica basato su pull. Ciò è importante nello scenario in cui il sistema di messaggistica deve soddisfare diversi tipi di consumatori con diverse capacità di elaborazione. Con il sistema basato su Pull il consumatore può consumare in base alla propria capacità in cui i sistemi push spingono i messaggi indipendentemente dallo stato del consumatore, mettendo così il consumatore ad alto rischio.

RabbitMQ è un broker di messaggi per scopi generici tradizionale. Consente ai server Web di rispondere rapidamente alle richieste e di inviare messaggi a più servizi. I publisher sono in grado di pubblicare messaggi e renderli disponibili per le code, in modo che i consumatori possano recuperarli. La comunicazione può essere asincrona o sincrona.

D'altra parte, Apache Kafka non è solo un broker di messaggi. Inizialmente è stato progettato e implementato da LinkedIn al fine di fungere da coda di messaggi. Dal 2011, Kafka è stato aperto e si è rapidamente evoluto in una piattaforma di streaming distribuita, utilizzata per l'implementazione di pipeline di dati in tempo reale e applicazioni di streaming.

È scalabile orizzontalmente, tollerante ai guasti, malvagio veloce e funziona in produzione in migliaia di aziende.

Le organizzazioni moderne hanno varie pipeline di dati che facilitano la comunicazione tra sistemi o servizi. Le cose diventano un po 'più complicate quando un numero ragionevole di servizi deve comunicare tra loro in tempo reale.

L'architettura diventa complessa poiché sono necessarie varie integrazioni per consentire l'intercomunicazione di questi servizi. Più precisamente, per un'architettura che comprende m servizi sorgente e n target, è necessario scrivere nxm integrazioni distinte. Inoltre, ogni integrazione viene fornita con una specifica diversa, il che significa che potrebbe essere necessario un protocollo diverso (HTTP, TCP, JDBC, ecc.) O una diversa rappresentazione dei dati (binario, Apache Avro, JSON, ecc.), Rendendo le cose ancora più difficili . Inoltre, i servizi di origine potrebbero indirizzare un aumento del carico dalle connessioni che potrebbero influire sulla latenza.

Apache Kafka porta a architetture più semplici e gestibili, disaccoppiando pipeline di dati. Kafka funge da sistema distribuito ad alta velocità in cui i servizi di origine inviano flussi di dati, rendendoli disponibili per i servizi di destinazione per estrarli in tempo reale.

Inoltre, sono disponibili molte interfacce utente open source e di livello enterprise per la gestione dei cluster Kafka. Per maggiori dettagli, consultare i miei articoli Panoramica degli strumenti di monitoraggio dell'interfaccia utente per i cluster Apache Kafka e Perché Apache Kafka?

La decisione di scegliere RabbitMQ o Kafka dipende dai requisiti del progetto. In generale, se si desidera un broker di messaggi pub-sub semplice / tradizionale, selezionare RabbitMQ. Se vuoi costruire un'architettura guidata dagli eventi sulla quale la tua organizzazione agirà in tempo reale sugli eventi, scegli Apache Kafka in quanto fornisce più funzionalità per questo tipo di architettura (ad esempio Kafka Streams o ksqlDB).

So che è un po 'tardi e forse lo hai già, indirettamente, detto, ma ancora una volta, Kafka non è affatto una coda, è un registro (come qualcuno ha detto sopra, basato sul sondaggio).

Per semplificare, il caso d'uso più ovvio in cui dovresti preferire RabbitMQ (o qualsiasi techno di coda) rispetto a Kafka è il seguente:

Hai più consumatori che consumano da una coda e ogni volta che c'è un nuovo messaggio nella coda e un consumatore disponibile, vuoi che questo messaggio venga elaborato. Se osservi attentamente come funziona Kafka, noterai che non sa come farlo, a causa del ridimensionamento delle partizioni, avrai un consumatore dedicato a una partizione e avrai problemi di fame. Problema che può essere facilmente evitato utilizzando la semplice techno di coda. Puoi pensare di utilizzare un thread che invierà i diversi messaggi dalla stessa partizione, ma ancora una volta, Kafka non ha alcun meccanismo di riconoscimento selettivo.

Il massimo che puoi fare è fare come quei ragazzi e provare a trasformare Kafka come una coda: https://github.com/softwaremill/kmq

Yannick

Usa RabbitMQ quando:

• Non è necessario gestire Bigdata e si preferisce una comoda interfaccia utente integrata per il monitoraggio
• Non sono necessarie code replicabili automaticamente
• Nessun abbonato multiplo per i messaggi: poiché a differenza di Kafka che è un registro, RabbitMQ è una coda e i messaggi vengono rimossi una volta consumati e il riconoscimento è arrivato
• Se hai i requisiti per usare i caratteri jolly e regex per i messaggi
• Se la definizione della priorità del messaggio è importante

In breve: RabbitMQ è utile per casi d'uso semplici, con traffico ridotto di dati, con il vantaggio di una priorità di priorità e opzioni di routing flessibili. Per dati di grandi dimensioni e alta produttività utilizzare Kafka.

Fornirò una risposta obiettiva basata sulla mia esperienza con entrambi, salterò anche la teoria dietro di loro, assumendo che tu lo sappia già e / o altre risposte abbiano già fornito abbastanza.

RabbitMQ : Sceglierei questo se i miei requisiti sono abbastanza semplici da gestire la comunicazione di sistema attraverso canali / code, la conservazione e lo streaming non sono un requisito. Ad esempio, quando il sistema di produzione ha creato l'asset, questo notifica al sistema di accordo di configurare i contratti e così via.

Kafka : Requisito di approvvigionamento di eventi principalmente, quando potrebbe essere necessario gestire flussi (a volte infiniti), un'enorme quantità di dati contemporaneamente correttamente bilanciati, riprodurre gli offset al fine di garantire un determinato stato e così via. Tieni presente che questa architettura porta anche una maggiore complessità, poiché include concetti come argomenti / partizioni / broker / messaggi di tombe, ecc. Come un'importanza di prima classe.

L'unico vantaggio che mi viene in mente è la funzione Transazionale, tutto il resto può essere fatto usando Kafka

Il ridimensionamento di entrambi è difficile in modo distribuito tollerante ai guasti, ma vorrei dire che è molto più difficile su larga scala con RabbitMQ. Non è banale capire Pala, Federazione, Coda messaggi specchiati, ACK, problemi di memoria, tolleranza agli errori, ecc. Non dire che non avrete problemi specifici con Zookeeper ecc su Kafka, ma ci sono meno parti mobili da gestire. Detto questo, ottieni uno scambio Polyglot con RMQ che non con Kafka. Se vuoi lo streaming, usa Kafka. Se desideri un IoT semplice o una consegna simile di pacchetti ad alto volume, usa Kafka. Si tratta di consumatori intelligenti. Se si desidera la flessibilità del msg e una maggiore affidabilità con costi più elevati e possibilmente una certa complessità, utilizzare RMQ.

Se hai esigenze di routing complesse e desideri che una GUI integrata controlli il broker, RabbitMQ potrebbe essere la soluzione migliore per la tua applicazione. Altrimenti, se stai cercando un broker di messaggi per gestire un throughput elevato e fornire l'accesso alla cronologia dei flussi, Kafka è probabilmente la scelta migliore.

Apache Kafka è una scelta popolare per alimentare pipeline di dati. Apache kafka ha aggiunto kafka stream per supportare i più diffusi casi d'uso etl. KSQL semplifica la trasformazione dei dati all'interno della pipeline, preparando i messaggi ad atterrare in modo pulito in un altro sistema. KSQL è il motore SQL di streaming per Apache Kafka. Fornisce un'interfaccia SQL interattiva potente e facile da usare per l'elaborazione in streaming su Kafka, senza la necessità di scrivere codice in un linguaggio di programmazione come Java o Python. KSQL è scalabile, elastico, tollerante ai guasti e in tempo reale. Supporta una vasta gamma di operazioni di streaming, tra cui filtraggio dei dati, trasformazioni, aggregazioni, join, finestre e sessioni.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq non è una scelta popolare per i sistemi etl, ma per quei sistemi in cui richiede semplici sistemi di messaggistica con un throughput inferiore.

Mi rendo conto che questa è una vecchia domanda, ma uno scenario in cui RabbitMQ potrebbe essere una scelta migliore è quando si tratta di redazione dei dati.

Con RabbitMQ, per impostazione predefinita una volta che il messaggio è stato consumato, viene eliminato. Con Kafka, per impostazione predefinita, i messaggi vengono conservati per una settimana. È comune impostarlo su un tempo molto più lungo o addirittura non cancellarli mai.

Mentre entrambi i prodotti possono essere configurati per conservare (o non conservare) i messaggi, se la conformità CCPA o GDPR è un problema, preferirei RabbitMQ.

Kafka è migliore di RabbitMQ in termini di produttività, durata, latenza. Se ti aspetti transazioni inferiori a 10k / sec, puoi scegliere RabbitMQ, ma anche questo dipende dalla tua implementazione.

Ho implementato Kafka nel nostro prodotto dove gestivamo più di 70.000 transazioni al secondo e la latenza era in media di 15 ms con pochi picchi che raggiungevano i 40 ms. La dimensione dell'argomento era 100kb.

PFB più punti dati su KAFKA e RabbitMQ: Apache Kafka include il broker stesso, che in realtà è la parte più conosciuta e più popolare di esso, ed è stato progettato e commercializzato in modo prominente verso scenari di elaborazione dei flussi. Inoltre, Apache Kafka ha recentemente aggiunto Kafka Streams che si posiziona come alternativa alle piattaforme di streaming come Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow e Spring Cloud Data Flow. La documentazione fa un buon lavoro nel discutere casi d'uso comuni come il monitoraggio delle attività del sito Web, le metriche, l'aggregazione dei registri, l'elaborazione dei flussi, il reperimento di eventi e i registri di commit. Uno di quei casi d'uso che descrive è la messaggistica, che può generare confusione. Quindi scompattiamolo un po 'e otteniamo un po' di chiarezza su quali scenari di messaggistica sono i migliori per Kafka, come:

Streaming da A a B senza routing complesso, con throughput massimo (100k / sec +), erogato in ordine partizionato almeno una volta. Quando l'applicazione deve accedere alla cronologia dei flussi, consegnata in ordine partizionato almeno una volta. Kafka è un archivio di messaggi duraturo e i clienti possono ottenere un "replay" del flusso di eventi su richiesta, al contrario dei broker di messaggi più tradizionali in cui una volta che un messaggio è stato consegnato, viene rimosso dalla coda. Sourcing degli eventi di elaborazione dei flussi RabbitMQ è una soluzione di messaggistica di uso generale, spesso utilizzata per consentire ai server Web di rispondere rapidamente alle richieste invece di essere costretti a eseguire procedure pesanti in termini di risorse mentre l'utente attende il risultato. È anche utile per distribuire un messaggio a più destinatari per il consumo o per bilanciare i carichi tra i lavoratori a carico elevato (20k + / sec). Quando le tue esigenze vanno oltre la velocità effettiva, RabbitMQ ha molto da offrire: funzionalità per consegna affidabile, routing, federazione, HA, sicurezza, strumenti di gestione e altre funzionalità. Esaminiamo alcuni scenari migliori per RabbitMQ, come:

L'applicazione deve funzionare con qualsiasi combinazione di protocolli esistenti come AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. È necessario un controllo / garanzie di consistenza più precisi per singolo messaggio (code di messaggi in sospeso, ecc.) Tuttavia, Kafka ha recentemente aggiunto un supporto migliore per le transazioni. La tua applicazione ha bisogno di varietà in punto a punto, richiesta / risposta e pubblicazione / sottoscrizione della messaggistica Routing complesso per i consumatori, integrazione di più servizi / app con logica di routing non banale RabbitMQ può anche affrontare efficacemente molti dei casi di utilizzo forte di Kafka sopra, ma con il aiuto di software aggiuntivo. RabbitMQ viene spesso utilizzato con Apache Cassandra quando l'applicazione deve accedere alla cronologia dei flussi o con il plug-in LevelDB per applicazioni che richiedono una coda "infinita", ma nessuna delle funzionalità viene fornita con RabbitMQ stesso.

La risposta breve è "riconoscimenti di messaggi". RabbitMQ può essere configurato per richiedere conferme di messaggi. Se un ricevitore fallisce, il messaggio ritorna in coda e un altro destinatario può riprovare. Mentre puoi farlo in Kafka con il tuo codice, funziona con RabbitMQ immediatamente.

Nella mia esperienza, se hai un'applicazione che ha i requisiti per interrogare un flusso di informazioni, Kafka e KSql sono la soluzione migliore. Se vuoi un sistema di accodamento, stai meglio con RabbitMQ.

La risposta più votata copre la maggior parte, ma vorrei evidenziare il punto di vista del caso d'uso di luce. Kafka può fare quel coniglio mq può fare, la risposta è sì ma può coniglio mq fare tutto quello che fa kafka, la risposta è no. Quindi qual è la cosa che coniglio mq non può fare che distingue kafka, ovvero l'elaborazione distribuita dei messaggi. Con questo ora rileggi la risposta più votata e avrà più senso. Per elaborare, prendi un caso d'uso in cui è necessario creare un sistema di messaggistica che abbia un throughput molto elevato, ad esempio "Mi piace" in Facebook e per questo hai scelto coniglio mq. Hai creato uno scambio e una coda e un consumatore in cui tutti gli editori (in questo caso gli utenti FB) possono pubblicare messaggi di "Mi piace". Poiché la tua produttività è elevata, creerai più thread nel consumatore per elaborare i messaggi in parallelo ma sei ancora limitato dalla capacità hardware della macchina su cui è in esecuzione il consumatore. Supponendo che un consumatore non sia sufficiente per elaborare tutti i messaggi: cosa faresti? Puoi aggiungere un altro consumatore in coda? No, non puoi farlo. Puoi creare una nuova coda e associare quella coda allo scambio che pubblica il messaggio "Mi piace", la risposta non è causa perché i messaggi verranno elaborati due volte. Questo è il problema principale che kafka risolve. Ti permette di creare partizioni distribuite (Coda in coniglio mq) e consumatore distribuito che parlano tra loro. Ciò garantisce che i messaggi in un argomento vengano elaborati dai consumatori distribuiti in vari nodi (Macchine). I broker Kafka garantiscono che i messaggi vengano bilanciati in base al carico in tutte le partizioni di tale argomento. Il gruppo di consumatori si assicura che tutti i consumatori si parlino e il messaggio non venga elaborato due volte. Ma nella vita reale non affronterai questo problema a meno che il tuo through put non sia seriamente alto perché coniglio mq può anche elaborare i dati molto velocemente anche con un solo consumatore.