MQTT
Ein kompaktes Publish-Subscribe-Protokoll, das für intermittierende Netzwerke, eingeschränkte Geräte, hierarchische Topics und Broker-Push-Zustellung entwickelt wurde.
Am besten geeignet für Device-to-Cloud- und Command-and-Control-Messaging.
Protokollvergleich
MQTT vs. Kafka: Geräte-Messaging oder dauerhaftes Event-Streaming?
Verwenden Sie MQTT allein für Live-Geräteverbindungen und Befehle, wenn kein wiederholbares Backend-Log benötigt wird. Nutzen Sie Kafka allein für vertrauenswürdige Backend-Producer und persistente Ereignisverarbeitung. Kombinieren Sie beide, wenn eingeschränkte Geräte MQTT-Sessions am Edge benötigen und mehrere Backend-Consumer gespeicherte, wiederholbare Ereignisse hinter einer kontrollierten Bridge verarbeiten sollen.
Vergleichen Sie das Betriebsmodell, nicht nur den Durchsatz
Die Protokolle lösen unterschiedliche Grenzen. MQTT optimiert die Geräteverbindung; Kafka optimiert das dauerhafte Verarbeitungsrückgrat.
Apache Kafka
Ein verteiltes Ereignisprotokoll für persistente Aufbewahrung, partitionierten Durchsatz, Consumer-gesteuerte Offsets, Replay und Stream-Verarbeitung.
Am besten für Service-zu-Service-Ereignispipelines, Analysen und Wiedergabe geeignet.
| Fähigkeit | MQTT | Kafka |
|---|---|---|
| Lebenszyklus der Geräteverbindung | Passend für native Anwendungen: schlanke Clients, Keepalive, Sitzungen, Reconnect und Last Will | Backend-Clients setzen eine stabile Konnektivität und Kafka-Protokollunterstützung voraus |
| Kernmodell | Vermitteltes Publish-Subscribe mit hierarchischen Topics | Partitioniertes Nur-Anhang-Protokoll mit Consumer-Offsets |
| Typische Clients | Sensoren, eingebettete Geräte, Gateways, mobile Clients | Backend-Dienste, Konnektoren, Stream-Prozessoren |
| Lieferung | Der Broker stellt passende Nachrichten zu; QoS 0, 1 oder 2 | Consumer lesen Datensätze und bestätigen Offsets pro Consumer Group |
| Command-Downlink | Vom Broker gesendete Befehls-Topics mit gerätespezifischer Autorisierung, Ablauf und Bestätigungen | Erfordert ein Anwendungsgateway, um Ereignisse zu autorisieren und in Gerätebefehle zu übersetzen |
| Aufbewahrung und Wiedergabe | Retained Messages und Session-Queues; kein allgemeines Ereignisarchiv | Persistente zeit- oder größenbasierte Aufbewahrung mit Wiedergabe ab einem Offset |
| Reihenfolge und Partitionierung | Die Reihenfolge gilt nur innerhalb einer Client-Verbindung und Topic-Zustellung; kein Consumer-Partitionsmodell | Ein Datensatzschlüssel wählt eine Partition aus; Die Ordnung ist nur innerhalb dieser Partition gewährleistet |
| Unabhängige Consumer | Subscriptions verteilen Live-Nachrichten per Fan-out; Shared Subscriptions teilen die Arbeit ohne persistente Offsets | Consumer Groups verwalten unabhängige Offsets und skalieren die Verarbeitung über Partitionen hinweg |
| Routenführung | Hierarchische Topic-Filter mit +- und #-Platzhaltern | Flache Topics und Partitionen; Routing gehört in Produzenten oder Prozessoren |
| Netzwerkannahmen | Entwickelt für geringe Bandbreite, hohe Latenz und die erneute Verbindung von Clients | Entwickelt für stabile Konnektivität zu Rechenzentren oder Cloud-Diensten |
Wählen Sie aus, wo sich die Daten kreuzen
Ein einziges System kann beide nutzen, ohne ihre Verantwortlichkeiten zu duplizieren.
Wählen Sie MQTT
Bei eingeschränkten oder zeitweise verbundenen Clients benötigen Telemetrie, Befehle, Sitzungsverhalten und Fanout auf Topic-Ebene einen geringen Overhead.
Wählen Sie Kafka
Wenn Backend-Teams einen persistenten Ereignisverlauf, mehrere unabhängige Consumer, Replay, Reihenfolge innerhalb von Partitionen und Stream-Verarbeitung benötigen.
Benutzen Sie beides
Wenn MQTT Gerätesitzungen beendet, fließen ausgewählte Ereignisse in Kafka für dauerhafte Analysen, Anreicherung und nachgelagerte Produkte.
Eine praktische MQTT-zu-Kafka-Grenze
Sorgen Sie dafür, dass die Verantwortlichkeiten im Protokoll explizit bleiben, damit Wiedergabe, Gegendruck und Autorisierung verständlich bleiben.
1. Authentifizieren Sie sich vor der Bridge
Der MQTT-Broker authentifiziert jedes Gerät und erzwingt dessen Publish-Topics. Die Bridge vertraut dem vom Broker autorisierten Routing, nicht einer Geräte-ID aus der Payload.
2. Ordnen Sie Topics bewusst zu
Abonnieren Sie nur freigegebene Telemetrie-Filter. Ordnen Sie diese einer kleinen, nach Ereignisdomäne gegliederten Menge von Kafka-Topics zu, statt jedes MQTT-Topic eins zu eins nach Kafka zu kopieren.
3. Validieren und in ein Envelope einbetten
Validieren Sie versionierte Payloads, leiten Sie Mandanten- und Gerätekontext aus dem autorisierten Topic ab und ergänzen Sie vor dem Schreiben nach Kafka Aufnahmezeit und eine stabile Ereignis-ID.
4. Passenden Partition Key wählen
Verwenden Sie als Record Key die kleinste fachliche Einheit, für die eine Reihenfolge erforderlich ist – häufig die Geräte- oder Asset-ID. Kafka garantiert keine globale Reihenfolge über Partitionen hinweg.
5. Wiederholungen begrenzen und Fehler in die DLQ leiten
Bei vorübergehenden Wiederholungen kommt es zu Fehlern mit Backoff. Senden Sie ungültige oder erschöpfte Datensätze mit Angabe des Grundes an eine eingeschränkte DLQ und geben Sie dann eine Warnung aus. Schleifen Sie sie niemals stillschweigend.
6. Messen Sie beide Seiten
Korrelieren Sie MQTT-Client und Topic mit Kafka Topic, Partition, Offset, Ereignis-ID, Wiederholungsanzahl, DLQ-Rate, Warteschlangenalter und End-to-End-Latenz ohne Protokollierungsgeheimnisse.
7. Halten Sie Befehle auf einem geschlossenen Rückweg
Ein separater Dienst muss von Kafka abgeleitete Aktionen autorisieren, Vorgangs-ID und Ablauf hinzufügen, über eine befehlsspezifische MQTT-Identität veröffentlichen und Gerätebestätigungen abgleichen.
Referenzfluss und Eigentumsübergabe
- 01
Geräteflotte
Einzigartige Identität; versionierte Telemetrie
- 02
MQTT-Broker
TLS, Sitzungen, Topic ACLs, Befehlsübermittlung
- 03
Ingestion-Bridge
Schema, Envelope, Wiederholungen, DLQ
- 04
Kafka-Topics
Partitionierte Aufbewahrung und Wiedergabe
- 05
Consumer Groups
Unabhängige Bearbeitung und Offsets
Ausführbare lokale Brücke mit expliziten Einschränkungen
Das Repository-Beispiel startet Mosquitto und Redpanda in reinen Loopback-Containern, validiert ein synthetisches Telemetrieschema, partitioniert Kafka-Datensätze nach Geräte-ID, begrenzt Wiederholungsversuche und leitet ungültige Datensätze an eine DLQ weiter. Es ist ein Lernbeispiel, kein Produktions-Connector: Der anonyme lokale Broker kennt keine Geräteidentitäten, und die Bridge hat zwischen MQTT- und Kafka-Bestätigung keinen persistenten Puffer.
Vom Repository-Stammverzeichnis ausführen
docker compose -f public/examples/mqtt-kafka-bridge/compose.yaml up -d
pnpm mqtt:kafka-bridge
# In a second shell, publish a synthetic event
docker compose -f public/examples/mqtt-kafka-bridge/compose.yaml exec mosquitto \
mosquitto_pub -h 127.0.0.1 -t lab/device-042/telemetry -q 1 \
-m '{"eventId":"evt-001","recordedAt":"2026-01-01T00:00:00Z","value":21.4}'Protokoll- und Implementierungsquellen
MQTT vs. Kafka FAQ
Kann Kafka einen MQTT-Broker ersetzen?
Kafka ist kein Drop-in-Gerätebroker. Es stellt keine MQTT-Sitzungen, QoS-Flows, aufbewahrte Nachrichten, hierarchische Topic-Filter oder denselben eingeschränkten Client-Footprint bereit.
Kann MQTT Kafka für den Ereignisverlauf ersetzen?
MQTT kann Session-Nachrichten puffern und den letzten Wert eines Topics beibehalten. Es ist jedoch kein langlebiges, wiederholbares Ereignisprotokoll für viele unabhängige Backend-Consumer.
Wo soll eine MQTT-zu-Kafka-Brücke verlaufen?
Führen Sie es an einer kontrollierten Aufnahmegrenze aus, an der Anmeldeinformationen, Schemata, Wiederholungsverhalten, Partitionsschlüssel und die Behandlung unzustellbarer Nachrichten verwaltet und beobachtet werden können.
Verwandte Architekturführer
Fahren Sie von den Architekturgrenzen zur MQTT-Implementierung, Sicherheit, Betriebsmodell, Flottenskalierung und Planauswahl fort.
Browser MQTT über WSS
Verstehen Sie den Browsertransport, MQTT Verantwortungsgrenzen und das Wiederverbindungsverhalten.
MQTT-Tutorial
Verfolgen Sie eine Nachricht von der Clientverbindung über die Topic-Zustellung.
MQTT Sicherheit
Schützen Sie Geräteidentität, Transport und Topic-Berechtigungen.
Verwaltete vs. selbstgehostete MQTT
Weisen Sie den Besitz für Broker-Upgrades, Verfügbarkeit und Sicherheitsvorgänge zu.
Skalierung von MQTT-Flotten
Planen Sie Kapazität für Verbindungen, Subscriptions, Reconnects und Regionen, bevor Sie nachgelagerte Pipelines hinzufügen.
RunMQTT-Preise
Vergleichen Sie Managed-MQTT-Broker-Tarife für die Geräteverbindungsebene.