Possiamo avere una forte capacità di routing con Apache Kafka simile a RabbitMq?

Question

Stiamo provando a valutare Kafka e sostituire Rabbit Mq nel nostro software.

Sappiamo i vantaggi di Kafka in termini di RabbitMq rispetto al consumo offline, enorme persistenza, prestazioni eccellenti, bassa latenza e throughput elevato.

Ma abbiamo bisogno della funzionalità del modo in cui RabbitMq ha con lo scambio di argomenti il routing granulare per il consumo eterogeneo.

In una certa misura possiamo ottenere questo risultato disponendo di un numero maggiore di partizioni per broker in Kafka. Ma ha i propri limiti come il sovraccarico dei metadati dell'argomento su znode, aumentare la latenza.

Il nostro caso d'uso consiste nel filtrare i dati all'interno della partizione. Supponi di avere 100 dati del sensore di tipo simile in una partizione. Il consumatore può avere la possibilità di selezionare solo alcuni dei dati del sensore e ignorare il resto.

Possiamo fare il filtraggio/instradamento sul lato dell'applicazione (consumatore) ma sembra non essere riutilizzabile e sovraccarico aggiuntivo da ogni lato del consumatore.

C'è un modo in cui Kafka può fornire funzionalità di routing grazie al numero ottimale di partizioni?

Grazie, Ashish

Answer 1

modello di messaggistica di Kafka è il modello molto più semplice di RabbitMQ, e gli utenti sono saggi di utilizzare le poche astrazioni che esso fornisce come erano destinati. In realtà, gli argomenti sono l'unico livello di routing che dovrebbe mai essere fatto in Kafka. Le partizioni servono solo per ridimensionare, fornire ordine (ma solo all'interno della partizione, che è un problema notevole per la scalabilità se si dispone di un'applicazione dipendente dall'ordine) e facilitare i consumatori concorrenti all'interno di un argomento.

Il problema con il routing a livello di partizioni è che non è scalabile perché le partizioni sono l'elemento di Kafka che fornisce scalabilità (almeno a livello di messaggistica). Ovviamente, Kafka non è progettato per il routing granulare. È progettato per messaggi pub/sub persistenti, affidabili, scalabili. Né sono partizioni progettate per scalare attraverso il cluster. Per loro stessa natura, le partizioni sono locali per uno o alcuni nodi Kafka (a seconda del fattore di replicazione dell'argomento), ma Kafka diffonde più partizioni all'interno di un argomento attraverso il cluster. Ciò significa che c'è un potenziale di hot spotting se i messaggi favoriscono alcune partizioni particolari invece di essere equamente distribuite tra le partizioni in un argomento (motivo per cui il produttore di Kafka normalmente gestisce il partizionamento per te).

In termini di filtraggio lato client, penso che tu abbia ragione: mi sembra che ci siano molte risorse sprecate per me, ma forse non mi piacciono troppo le risorse sprecate.

In breve, penso che potresti rischiare di scavarti in un buco se cerchi di pensare alle astrazioni di Kafka in termini così complessi. Kafka è progettato e ottimizzato per distribuire il carico tramite partizioni, quindi cooptarle per un altro, anche se vagamente simile, non è certo l'ideale.

Ho la sensazione che tu possa gestire il tuo caso d'uso nel contesto delle funzionalità di Kafka. Trovo che la sfida più grande con schemi di routing complessi nell'ambito del framework di Kafka sia la prevenzione di dati duplicati in più argomenti, ma una volta compreso come più applicazioni possano consumare da posizioni diverse all'interno dello stesso argomento, il problema sembra scomparire. In questo senso, è importante pensare a Kafka più come un log che come una coda.

In una nota a margine, penso che la tua preoccupazione con znode richiesta per gestire le partizioni sia infondata. Se hai abbastanza argomenti e partizioni per consumare la memoria dei tuoi nodi ZooKeeper (una tonnellata), probabilmente avrai già problemi di risorse molto più grandi.