{"id":219923,"date":"2026-03-04T12:33:29","date_gmt":"2026-03-04T11:33:29","guid":{"rendered":"https:\/\/liora.io\/de\/kafka-hat-endlich-queues-warum-dies-alles-veraendert"},"modified":"2026-03-04T15:56:34","modified_gmt":"2026-03-04T14:56:34","slug":"kafka-hat-endlich-queues-warum-dies-alles-veraendert","status":"publish","type":"post","link":"https:\/\/liora.io\/de\/kafka-hat-endlich-queues-warum-dies-alles-veraendert","title":{"rendered":"Kafka hat endlich Queues: Warum dies alles ver\u00e4ndert"},"content":{"rendered":"<p><strong>Confluent hat \u201eQueues for Kafka\u201c eingef\u00fchrt, eine neue Funktion, die traditionelle Message-Queuing-F\u00e4higkeiten in die Apache Kafka Streaming-Plattform integriert. Dies erm\u00f6glicht 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\u00fcgbar und f\u00fchrt \u201eshare groups\u201c ein, die es mehreren Consumern erlauben, Nachrichten aus derselben Partition gleichzeitig zu verarbeiten \u2013 eine bedeutende Abkehr vom traditionellen Kafka-Modell mit einem Consumer pro Partition.<\/strong><\/p>\n<p>Diese Entwicklung markiert einen grundlegenden Wandel f\u00fcr <strong>Apache Kafka<\/strong>, das traditionell voraussetzte, dass jede Partition von nur einem Consumer gleichzeitig verarbeitet wird. Die neue F\u00e4higkeit, basierend auf <strong>KIP-932<\/strong> und in die Kernver\u00f6ffentlichung von Apache Kafka 4.2 aufgenommen, erm\u00f6glicht es Organisationen, ihre Infrastruktur zu konsolidieren, indem sowohl Streaming- als auch traditionelle Queuing-Workloads auf einer einzigen Plattform abgewickelt werden, so die Ank\u00fcndigung von Confluent.<\/p>\n<p>Die Funktion f\u00fchrt <strong>per-message acknowledgment<\/strong> ein und ersetzt damit Kafkas traditionelle offset-basierte Batch-Commits. Wenn ein Consumer eine Nachricht abruft, belegt der Broker diese Nachricht mit einer <strong>30-Sekunden-Sperre<\/strong> und verlangt explizite Ma\u00dfnahmen wie die Best\u00e4tigung der erfolgreichen Verarbeitung oder die Freigabe zur erneuten Zustellung, wie Confluent in seiner technischen Dokumentation erl\u00e4utert. Dies erm\u00f6glicht <strong>elastic scaling<\/strong>, wodurch die Anzahl der Consumer unabh\u00e4ngig von der Partitionsanzahl angepasst werden kann, um variable Workloads zu bew\u00e4ltigen.<\/p>\n<p><strong>Technical Trade-offs<\/strong><\/p>\n<p>Die bedeutendste \u00c4nderung betrifft das <strong>message ordering<\/strong>. W\u00e4hrend herk\u00f6mmliche Kafka-Consumer-Gruppen eine Verarbeitung in strikter Reihenfolge pro Partition garantieren, opfern Share-Groups diese Garantie, um eine parallele Verarbeitung zu erm\u00f6glichen, so Confluent. Nachrichten bleiben in der Reihenfolge gespeichert, k\u00f6nnen aber gleichzeitig von mehreren Consumern verarbeitet werden und dabei die Reihenfolge verlieren. Die aktuelle Version bietet <strong>at-least-once delivery<\/strong>-Semantik, wobei eine exactly-once Semantik f\u00fcr eine sp\u00e4tere Integration geplant ist.<\/p>\n<p>F\u00fcr <strong>Enterprise- und Dedicated clusters<\/strong> in der Confluent Cloud ist die Funktion sofort verf\u00fcgbar, w\u00e4hrend die Unterst\u00fctzung f\u00fcr Standard-Cluster f\u00fcr die zweite Jahresh\u00e4lfte 2026 vorgesehen ist, teilte das Unternehmen mit. Die Funktionalit\u00e4t ist ohne zus\u00e4tzliche Geb\u00fchren erh\u00e4ltlich, abgesehen von den Standard-Verbrauchskosten f\u00fcr data ingress, egress und uptime, gem\u00e4\u00df der Preisdokumentation von Confluent.<\/p>\n<p><strong>Market Applications<\/strong><\/p>\n<p>Die Funktion richtet sich an operative Workloads, die von traditioneller Message-Queue-Semantik profitieren, einschlie\u00dflich <strong>task distribution<\/strong> an Worker-Pools, Service-to-Service-Kommunikation und asynchrone Job-Verarbeitung, so Confluent. Das Unternehmen empfiehlt jedoch weiterhin Standard-Kafka-Consumer-Gruppen f\u00fcr Anwendungsf\u00e4lle, die eine strikte Ordnung und durchsatzstarke Batch-Verarbeitung erfordern, wie etwa <strong>event sourcing<\/strong> und Streaming-Analytics.<\/p>\n<p>Confluent Cloud erweitert das Open-Source-Feature um eine dedizierte UI zur Verwaltung von share groups und f\u00fchrt eine <strong>\u201eshare lag\u201c-Metrik<\/strong> ein, \u00e4hnlich der Warteschlangentiefe, welche Auto-Scaling-Entscheidungen \u00fcber die Metrics API steuern kann, laut dem technischen Blog des Unternehmens.<\/p>\n<p>Zu den zuk\u00fcnftigen Verbesserungen geh\u00f6ren <strong>Dead Letter Queues<\/strong>, <strong>key-based ordering<\/strong> zur Wiederherstellung bestimmter Ordering-Garantien sowie die Integration mit Kafka-Transaktionen f\u00fcr exactly-once Semantics. Dies deutet auf eine kontinuierliche Investition in die Weiterentwicklung von Kafka zu einer umfassenden Datenplattform weit \u00fcber seine Streaming-Urspr\u00fcnge hinaus hin.<\/p>\n<div style=\"margin-top:3rem;padding-top:1.5rem;border-top:1px solid #e2e4ea;\">\n<h3 style=\"margin:0 0 0.75rem;font-size:1.1rem;letter-spacing:0.08em;text-transform:uppercase;\">\n    Sources<br \/>\n  <\/h3>\n<ul style=\"margin:0;padding-left:1.2rem;list-style:disc;\">\n<li>Confluent<\/li>\n<li>Apache Software Foundation<\/li>\n<\/ul>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Confluent hat \u201eQueues for Kafka\u201c eingef\u00fchrt, eine neue Funktion, die traditionelle Message-Queuing-F\u00e4higkeiten in die Apache Kafka Streaming-Plattform integriert. Dies erm\u00f6glicht 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\u00fcgbar und f\u00fchrt \u201eshare groups\u201c ein, die es mehreren Consumern erlauben, Nachrichten aus derselben Partition gleichzeitig zu verarbeiten \u2013 eine bedeutende Abkehr vom traditionellen Kafka-Modell mit einem Consumer pro Partition.<\/p>\n","protected":false},"author":87,"featured_media":219918,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"editor_notices":[],"footnotes":""},"categories":[2476,2475],"class_list":["post-219923","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-dev","category-nachrichten"],"acf":[],"_links":{"self":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/219923","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/users\/87"}],"replies":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/comments?post=219923"}],"version-history":[{"count":1,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/219923\/revisions"}],"predecessor-version":[{"id":219927,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/posts\/219923\/revisions\/219927"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/media\/219918"}],"wp:attachment":[{"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/media?parent=219923"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/liora.io\/de\/wp-json\/wp\/v2\/categories?post=219923"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}