Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Moderne Apache-Kafka-Cluster nutzen KRaft für Metadaten. Controller- und Broker-Rollen können getrennt oder kombiniert sein. Kapazität hängt von Retention, Partitionen, Replication Factor, Message-Größe sowie Disk-/Netz-Durchsatz ab.
Aktuelles KRaft verwaltet Cluster-Metadaten im Controller-Quorum und benötigt für neue KRaft-Cluster kein ZooKeeper. In Production Controller-Quorum und Broker-Kapazität getrennt betrachten; Combined Mode eher klein/Test.
Producer schreiben in Topic-Partitionen, Broker replizieren nach Replication Factor und Consumer Groups verteilen Partitionen auf Mitglieder.
Controller verwalten Metadata-Quorum, Broker Datenverkehr und Partition-IO. In größeren Production-Clustern schafft Trennung bessere Isolation.
Raw Ingest × Retention reicht nicht; Replicas, Segment-Overhead und Wachstumspuffer addieren.
Binary-Pfade variieren; Bootstrap-Server an eigenes Cluster anpassen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --statuskafka-topics.sh --bootstrap-server localhost:9092 --listkafka-topics.sh --bootstrap-server localhost:9092 --describe --topic eventskafka-consumer-groups.sh --bootstrap-server localhost:9092 --all-groups --describeNeue Broker verteilen Partitionen nicht automatisch perfekt; Partition Reassignment und Client-Kapazität separat planen.
Architektur zur Verwaltung von Kafka-Metadaten über Raft-basiertes Controller-Quorum ohne ZooKeeper.
Nein, aber schnelle Disks helfen bei intensiven Log Writes, Retention und Replication.
Abhängig von Throughput, Consumer-Parallelität, Ordering und Wachstum; keine pauschale Zahl.
Teilen Sie tägliche Events, Message-Größe, Retention, Replication Factor und Consumer-Anzahl; Broker/Controller-Topologie planen.