RabbitMQ vs Kafka vs ...

[c-nan]

Ik ben op zoek naar message broker software, tot op heden weinig tot geen ervaring hiermee. Om die reden is het lastig om voor een bepaald product te kiezen.

Eisen:
1. Meerdere consumers per topic.
2. De consumers moeten niet dezelfde berichten verwerken.
3. Berichten moeten na verwerkt te zijn automatisch verwijderd worden.

Eis 1 kan zowel met Kafka als met RabbitMQ.

Bij Kafka heb ik gelezen dat je per topic, meerdere partitions kunt aanmaken, aan een partition kan je weer een consumer toewijzen. Hiermee voldoe ik aan eis 2 (zie ook https://www.oreilly.com/l...53/assets/ktdg_04in03.png). Kan dit ook met RabbitMQ?

Bij RabbitMQ heb je een optie, zodra een bericht verwerkt/gelezen is dat deze automatisch wordt verwijderd. Hiermee voldoe ik ana eis 3. Bij Kafka kan dit niet, hier is de verwachting dat je er zelf een check voor maakt.

Het gaat om ~15.000.000 berichten per dag, niet verspreid over de hele dag, maar wordt dagelijks 1x de queue in gepusht. Bedoeling is dat deze berichten zo snel mogelijk parallel worden verwerkt, dus vandaar meerdere consumers per topic.

Wat zouden jullie aanraden?

[DiedX]

Wellicht Redis? https://redis.io/documentation

[NMe]

Redis is geschikt als cache, er een beetje een functionele message queue van maken die loads balanceert eist wat meer werk dan een product als Kafka of RabbitMQ.

c-nan schreef op zondag 5 mei 2019 @ 21:17:
Kan dit ook met RabbitMQ?

https://www.rabbitmq.com/...semaphores-with-rabbitmq/

[ Voor 101% gewijzigd door NMe op 06-05-2019 16:06 ]

[Montaner]

Ik neem aan dat je doel is om in je verwerkende applicatie parallel processing te doen? Maar je doet dit door meerdere instances te draaien welke niet aan load balancing doen en dat wil je oplossen met een message broker?

[P_de_B]

wil je het onpremise? Of is een SaaS-oplossing als Azure Service Bus een optie?

https://azure.microsoft.com/en-us/services/service-bus/

[Slamdance]

Wij gebruiken op werk Apache ActiveMQ.

Daar is het zo dat een topic er is er om 1 bericht naar alle luisterende consumers te sturen.
Een Queue wordt gebruik om een bericht maar naar 1 van de luisterende consumers te sturen. (je 2e eis)
Verwijderen van het bericht nadat deze is opgehaald door een consumer gebeurt bij ActiveMQ automatisch.

In onze situatie zie je dat de consumers netjes om de beurt een bericht van de queue af pakken. (maar hier gaat het om tientallen berichten verspreid over de dag)

ActiveMQ laat zich alleen lastig schalen. Het support alleen store and forward naar een andere broker of een Master-Slave setup.

[downtime]

Slamdance schreef op zondag 5 mei 2019 @ 22:26:
Wij gebruiken op werk Apache ActiveMQ.

Daar is het zo dat een topic er is er om 1 bericht naar alle luisterende consumers te sturen.
Een Queue wordt gebruik om een bericht maar naar 1 van de luisterende consumers te sturen. (je 2e eis)
Verwijderen van het bericht nadat deze is opgehaald door een consumer gebeurt bij ActiveMQ automatisch.

In onze situatie zie je dat de consumers netjes om de beurt een bericht van de queue af pakken. (maar hier gaat het om tientallen berichten verspreid over de dag)

ActiveMQ laat zich alleen lastig schalen. Het support alleen store and forward naar een andere broker of een Master-Slave setup.

Ik vraag me inderdaad ook af waarom TS perse met consumers en topics wil werken. Dat doe je volgens mij juist als je een bericht door meerdere consumers wilt laten verwerken. Hij wil dat juist uitsluiten en dan heeft ie volgens mij net het verkeerde mechanisme gekozen.

[SlaadjeBla]

Apache Kafka doet precies wat je wil, maar RabbitMQ ook. Het verschil zit hem in opslag, partitionering en clustermogelijkheden.

In Kafka ligt alles eenmaal opgeslagen vast in een partitie. De volgorde blijft gegarandeerd. Bij RabbitMQ kan een bericht terug worden gezet in de queue door een consumer en dan is de volgorde gewijzigd. Dus is de volgorde belangrijk, kies dan Kafka.

Hoe er gepartitioneerd wordt, bepaal je zelf. Door partitionering behoren alle records met dezelfde key tot dezelfde partitie en is hun volgorde van consumeren gegarandeerd.

Door een topic te partitioneren kun je schalen tot 1 consumer (vaak 1 proces of thread) per partitie. 1 consumer krijgt 1 of meer partities toegewezen, maar 1 partitie is altijd maar aan 1 consumer toegewezen. Een bericht wordt dus slechts eenmaal gelezen.

De documentatie van Kafka is erg goed. Ik zou daar eens beginnen lezen.