Kafkas Messaging-Modell ist viel einfacheres Modell als RabbitMQ, und die Benutzer sind weise die wenige Abstraktionen zu verwenden, dass es wie sie gemeint waren liefert. Tatsächlich sind Themen die einzige Routing-Ebene, die jemals in Kafka durchgeführt werden sollte. Partitionen dienen nur dazu, zu skalieren, Ordnung zu schaffen (aber nur innerhalb der Partition, was ein erhebliches Problem für die Skalierbarkeit ist, wenn Sie eine auftragsabhängige Anwendung haben) und gleichzeitige Konsumenten innerhalb eines Themas zu ermöglichen.
Das Problem mit dem Routing auf der Ebene von Partitionen ist, dass es nicht skalierbar ist, weil Partitionen das Element von Kafka sind, das Skalierbarkeit bietet (zumindest auf der Messaging-Schicht). Offensichtlich ist Kafka nicht für granulares Routing ausgelegt. Es ist für dauerhafte, zuverlässige, skalierbare Pub/Sub-Messaging ausgelegt. Es gibt auch keine Partitionen, die über den Cluster skaliert werden können. Aufgrund ihrer Beschaffenheit sind Partitionen lokal für einen oder wenige Kafka-Knoten (abhängig vom Replikationsfaktor des Themas), aber Kafka verteilt mehrere Partitionen innerhalb eines Themas im gesamten Cluster. Dies bedeutet, dass es Potenzial für Hot Spotting gibt, wenn Nachrichten eine bestimmte Partition bevorzugen und nicht gleichmäßig über Partitionen in einem Thema verteilt sind (weshalb der Kafka-Produzent normalerweise die Partitionierung für Sie übernimmt).
In Bezug auf die Filterung auf der Client-Seite, denke ich, dass Sie Recht haben: Das fühlt sich für mich wie eine Menge verschwendeter Ressourcen an, aber vielleicht mag ich einfach die verschwendeten Ressourcen nicht zu sehr.
Kurz gesagt, Sie können riskieren, sich in ein Loch zu graben, wenn Sie versuchen, an Kafkas Messaging-Abstraktionen in solch komplexen Begriffen zu denken. Kafka ist sehr darauf ausgelegt und optimiert, die Last über Partitionen zu verteilen, so dass die Kooptierung für einen anderen - wenn auch vage ähnlichen - Anwendungsfall sicherlich nicht ideal ist.
Ich habe das Gefühl, dass Sie Ihren Anwendungsfall im Kontext von Kafkas Funktionen verwalten können. Ich finde, dass die größte Herausforderung bei komplexen Routing-Schemata in Kafkas Themarahmen darin besteht, doppelte Daten innerhalb mehrerer Themen zu vermeiden, aber sobald Sie verstehen, wie mehrere Anwendungen von verschiedenen Positionen innerhalb desselben Themas konsumieren können, scheint dieses Problem zu verschwinden. In diesem Sinne ist es wichtig, Kafka mehr als ein Protokoll als als eine Warteschlange zu betrachten.
Nebenbei bemerkt, ich denke, dass Ihre Bedenken mit Znodes zur Verwaltung von Partitionen unbegründet ist. Wenn Sie genug Themen und Partitionen haben, um den Speicher Ihrer ZooKeeper-Knoten (eine Tonne) zu verbrauchen, sind Sie wahrscheinlich schon auf viel größere Ressourcenprobleme gestoßen.
Haben Sie jemals eine endgültige Lösung mit Kafka gefunden, die Ihren Routinganforderungen entspricht? Ich habe eine ähnliche Situation, in der ich eine Reihe von Apps habe, die in Gruppen von N separaten Abschnitten laufen, und ich möchte, dass Nachrichten, die für den Kontext von Gruppe A veröffentlicht wurden, von den anderen Anwendungen in derselben Gruppe A konsumiert werden. und nicht B. Ich mag die Idee nicht, dass alle Apps in allen Sets alle Nachrichten bekommen, und es liegt an ihnen, die für ihr eigenes Set herauszufiltern. –