Apache Kafka: kafka-storage.sh random-uuid, release 11 für clients und der Testbetrieb mit Gradle
Apache Kafka – Eine verteilte Event-Streaming-Plattform. Wir bauen und testen Apache Kafka mit den Java-Versionen 17 und 25.
Auf einen Blick
- Was ist das?
- Das README von apache/kafka beschreibt eine verteilte Ereignisplattform. Wir arbeiten Java-Vorgaben, Broker-Start, Gradle-Befehle und Prüfwerkzeuge ab.
- Für wen ist es gedacht?
- Kafka trägt dort, wo Ereignisse dauerhaft geordnet abgelegt und von mehreren Verarbeitern unabhängig gelesen werden sollen, und wo der Betrieb eines Brokers mit Java 17 möglich ist. Wer Warteschlangen- und Stromverarbeitung in einem System mit getrenntem Speicher sucht, findet bei Apache Pulsar eine andere Aufteilung.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Kafka als verteilte Ereignisplattform: Zuständigkeit laut README
Das README von apache/kafka beschreibt das Projekt als quelloffene verteilte Ereignisplattform. Als Verwendungszwecke nennt es Datenpipelines mit hohem Durchsatz, Streaming-Analysen, Datenintegration und geschäftskritische Anwendungen, und es spricht von Einsatz bei Tausenden von Unternehmen. Diese Zahl ist selbst berichtet und im Repository nicht belegt.
Die Aufgabe lässt sich knapp beschreiben. Ereignisse werden in eine geordnete, dauerhafte Folge geschrieben, von der beliebig viele Verarbeiter unabhängig voneinander lesen. Sender und Empfänger kennen sich nicht, und der Lesefortschritt liegt beim Empfänger. Ein später hinzukommender Verarbeiter kann alte Ereignisse erneut lesen, ohne dass der Sender etwas davon bemerkt.
Die Metadaten nennen Java als Sprache sowie die Apache-Lizenz 2.0. Zum Abrufzeitpunkt standen rund 33.600 Sterne und 15.400 Forks im Raum, als Standardbranch ist trunk eingetragen. Angaben zur letzten Aktivität am Quellstand und zu veröffentlichten Fassungen liegen im Repository nicht vor.
Java 17 und 25 im Bau, release 11 für clients und streams
Die Versionsvorgaben im README sind ungewöhnlich genau. Gebaut und getestet wird mit Java 17 und 25. Der Parameter release des Java-Übersetzers steht für die Module clients und streams auf 11, für alle übrigen auf 17, was nach Lesart des README die Kompatibilität mit den jeweiligen Mindestversionen sichert.
Diese Aufteilung hat eine unmittelbare Folge für den Einsatz. Wer die Client-Bibliothek in einer Anwendung auf Java 11 betreibt, bleibt unterstützt, während der Server-Teil Java 17 verlangt. Für die umgekehrte Richtung, also eine alte Laufzeitumgebung mit einem neuen Client, enthält das README keine Zusage.
Für Scala gilt eine klare Ansage: 2.13 ist die einzige unterstützte Version. Die Streams-Module werden auf Bytecode der Stufe 11 übersetzt, der Rest auf 17. Bei der Arbeit im Editor verlangt das README ausdrücklich JDK 17, auch wenn IntelliJ nach seinen Angaben die passende Java-Version je Modul selbst prüft. Für Eclipse steht der Aufgabe ./gradlew eclipse bereit.
kafka-storage.sh random-uuid, format --standalone und kafka-server-start.sh
Zum Start eines Brokers nennt das README eine dreizeilige Folge. Zunächst erzeugt ./bin/kafka-storage.sh random-uuid eine Cluster-Kennung, die in der Variablen KAFKA_CLUSTER_ID landet. Danach bereitet ./bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c config/server.properties den Speicher vor, und ./bin/kafka-server-start.sh config/server.properties nimmt den Server in Betrieb.
Der mittlere Schritt verdient Aufmerksamkeit, weil er Pflicht ist. Ohne die einmalige Formatierung startet der Server nicht, und die Kennung verbindet Speicher und Cluster miteinander. Der Schalter --standalone deutet auf einen Betrieb ohne zusätzlichen Koordinationsdienst hin, was die Zahl der mitzubetreuenden Komponenten verringert. Das README erläutert diesen Punkt nicht weiter.
Als Konfigurationsdatei dient config/server.properties. Welche Schlüssel darin gesetzt werden können, steht nicht im README; für den Einstieg verweist es auf die Schnellstartanleitung unter kafka.apache.org/quickstart.
docker run -p 9092:9092 apache/kafka:latest als zweiter Weg
Der zweite Weg zum laufenden Broker führt über ein Container-Image. Der Aufruf lautet docker run -p 9092:9092 apache/kafka:latest, und für Einzelheiten verweist das README auf die Datei docker/README.md im Repository.
Dieser Weg ist für einen ersten Kontakt attraktiv, weil er die Formatierung des Speichers abnimmt. Er bringt jedoch zwei Eigenheiten mit. Erstens enthält die Zeile die Bezeichnung latest, was bei jedem Zug eine andere Fassung bedeuten kann und für wiederholbare Umgebungen ungeeignet ist. Zweitens ist ausschließlich der Port 9092 freigegeben, was für den Zugriff von außerhalb des Container-Netzes genügt, weitergehende Anforderungen aber offenlässt.
Wer stattdessen aus den Quellen arbeitet, erzeugt mit ./gradlew clean releaseTarGz ein gepacktes Archiv, das unter ./core/build/distributions/ liegt. Für den laufenden Bau stehen daneben ./gradlew jar sowie ./gradlew srcJar bereit, und ./gradlew clean räumt die Ergebnisse ab.
./gradlew clients:test --tests und -PmaxTestRetries: der Testbetrieb
Der Testbetrieb ist der ausführlichste Teil des README. ./gradlew test führt Komponenten- und Integrationstests gemeinsam aus, während ./gradlew unitTest und ./gradlew integrationTest beide Gruppen trennen. Als instabil markierte Fälle laufen nur mit dem Schalter -Pkafka.test.run.flaky=true, ein deutlicher Hinweis darauf, dass die Testsuite bekannte Schwankungen kennt.
Einzelne Fälle lassen sich gezielt ansprechen. ./gradlew clients:test --tests RequestResponseTest startet eine Klasse, ./gradlew clients:test --tests org.apache.kafka.clients.MetadataTest.testTimeToNextUpdate eine einzelne Methode. Wer ohne Änderung am Code erneut testen will, ergänzt --rerun-tasks. Das README zeigt sogar eine Schleife, die einen Fall fünfhundertmal wiederholt, was nahelegt, dass manche Fehlerbilder erst nach vielen Durchläufen auftreten.
Für Wiederholungen bei Fehlern gibt es zwei Eigenschaften. -PmaxTestRetries=1 erlaubt einen erneuten Versuch je Fall, -PmaxTestRetryFailures=3 begrenzt die Gesamtzahl; voreingestellt sind Wiederholungen abgeschaltet. Abdeckungsberichte entstehen mit ./gradlew reportCoverage -PenableTestCoverage=true -Dorg.gradle.parallel=false.
Checkstyle, SpotBugs und der Vergleich mit Apache Pulsar
Zur statischen Prüfung nennt das README drei Werkzeuge. Checkstyle erzwingt einen einheitlichen Stil und lässt den Bau bei Verstößen scheitern, die Berichte liegen unter reports/checkstyle/. Spotless ordnet die Einbindungen, und vor einem Beitrag soll ./gradlew spotlessApply laufen. SpotBugs sucht nach Fehlermustern, aufgerufen über ./gradlew spotbugsMain spotbugsTest -x test. Ergänzend gibt es Mikromessungen im Verzeichnis jmh-benchmarks, ohne dass das README Ergebnisse nennt.
Die auffälligste Lücke betrifft die Veröffentlichung. Im Repository sind keine Releases hinterlegt, und eine Angabe zur letzten Aktivität fehlt. Veröffentlichungen laufen über die Projektseite statt über den Spiegel auf GitHub; wer eine bestimmte Fassung sucht, wird dort fündig. Ebenso fehlen im README Leistungswerte, obwohl von Datenpipelines mit hohem Durchsatz die Rede ist.
Als Alternative kommt Apache Pulsar infrage, wenn Warteschlangen- und Stromverarbeitung in einem System zusammenkommen sollen. Dort liegen Broker und Speicher getrennt, während beide Aufgaben bei Kafka im Broker sitzen. Diese Kopplung vereinfacht kleine Installationen und verlangt bei wachsender Last eigene Planung. Die Apache-Lizenz 2.0 erlaubt den kommerziellen Einsatz einschließlich angepasster Varianten bei Beachtung der Hinweispflichten.
Redaktionelles Fazit
Kafka trägt dort, wo Ereignisse dauerhaft geordnet abgelegt und von mehreren Verarbeitern unabhängig gelesen werden sollen, und wo der Betrieb eines Brokers mit Java 17 möglich ist. Wer Warteschlangen- und Stromverarbeitung in einem System mit getrenntem Speicher sucht, findet bei Apache Pulsar eine andere Aufteilung. Vor dem Einsatz sollte der Broker über kafka-storage.sh format mit eigener Cluster-Kennung gestartet werden, statt auf das Image apache/kafka:latest mit beweglicher Fassung zu setzen, und die Testsuite mindestens einmal vollständig durchlaufen.
Community-Notizen