Confluent hat „Queues for Kafka“ eingeführt, eine neue Funktion, die traditionelle Message-Queuing-Fähigkeiten in die Apache Kafka Streaming-Plattform integriert. Dies ermöglicht es Organisationen, sowohl Streaming- als auch Queuing-Workloads auf einem einzigen System zu verarbeiten. Die Funktion ist jetzt in der Confluent Cloud und Confluent Platform 7.7 verfügbar und führt „share groups“ ein, die es mehreren Consumern erlauben, Nachrichten aus derselben Partition gleichzeitig zu verarbeiten – eine bedeutende Abkehr vom traditionellen Kafka-Modell mit einem Consumer pro Partition.
Diese Entwicklung markiert einen grundlegenden Wandel für Apache Kafka, das traditionell voraussetzte, dass jede Partition von nur einem Consumer gleichzeitig verarbeitet wird. Die neue Fähigkeit, basierend auf KIP-932 und in die Kernveröffentlichung von Apache Kafka 4.2 aufgenommen, ermöglicht es Organisationen, ihre Infrastruktur zu konsolidieren, indem sowohl Streaming- als auch traditionelle Queuing-Workloads auf einer einzigen Plattform abgewickelt werden, so die Ankündigung von Confluent.
Die Funktion führt per-message acknowledgment ein und ersetzt damit Kafkas traditionelle offset-basierte Batch-Commits. Wenn ein Consumer eine Nachricht abruft, belegt der Broker diese Nachricht mit einer 30-Sekunden-Sperre und verlangt explizite Maßnahmen wie die Bestätigung der erfolgreichen Verarbeitung oder die Freigabe zur erneuten Zustellung, wie Confluent in seiner technischen Dokumentation erläutert. Dies ermöglicht elastic scaling, wodurch die Anzahl der Consumer unabhängig von der Partitionsanzahl angepasst werden kann, um variable Workloads zu bewältigen.
Technical Trade-offs
Die bedeutendste Änderung betrifft das message ordering. Während herkömmliche Kafka-Consumer-Gruppen eine Verarbeitung in strikter Reihenfolge pro Partition garantieren, opfern Share-Groups diese Garantie, um eine parallele Verarbeitung zu ermöglichen, so Confluent. Nachrichten bleiben in der Reihenfolge gespeichert, können aber gleichzeitig von mehreren Consumern verarbeitet werden und dabei die Reihenfolge verlieren. Die aktuelle Version bietet at-least-once delivery-Semantik, wobei eine exactly-once Semantik für eine spätere Integration geplant ist.
Für Enterprise- und Dedicated clusters in der Confluent Cloud ist die Funktion sofort verfügbar, während die Unterstützung für Standard-Cluster für die zweite Jahreshälfte 2026 vorgesehen ist, teilte das Unternehmen mit. Die Funktionalität ist ohne zusätzliche Gebühren erhältlich, abgesehen von den Standard-Verbrauchskosten für data ingress, egress und uptime, gemäß der Preisdokumentation von Confluent.
Market Applications
Die Funktion richtet sich an operative Workloads, die von traditioneller Message-Queue-Semantik profitieren, einschließlich task distribution an Worker-Pools, Service-to-Service-Kommunikation und asynchrone Job-Verarbeitung, so Confluent. Das Unternehmen empfiehlt jedoch weiterhin Standard-Kafka-Consumer-Gruppen für Anwendungsfälle, die eine strikte Ordnung und durchsatzstarke Batch-Verarbeitung erfordern, wie etwa event sourcing und Streaming-Analytics.
Confluent Cloud erweitert das Open-Source-Feature um eine dedizierte UI zur Verwaltung von share groups und führt eine „share lag“-Metrik ein, ähnlich der Warteschlangentiefe, welche Auto-Scaling-Entscheidungen über die Metrics API steuern kann, laut dem technischen Blog des Unternehmens.
Zu den zukünftigen Verbesserungen gehören Dead Letter Queues, key-based ordering zur Wiederherstellung bestimmter Ordering-Garantien sowie die Integration mit Kafka-Transaktionen für exactly-once Semantics. Dies deutet auf eine kontinuierliche Investition in die Weiterentwicklung von Kafka zu einer umfassenden Datenplattform weit über seine Streaming-Ursprünge hinaus hin.
Sources
- Confluent
- Apache Software Foundation
