Die Architektur von MQTT basiert auf dem Publish/Subscribe-Muster. Die Produzenten von Nachrichten (sog. Publisher) und die Empfänger der Nachrichten (sog. Subscriber) sind komplett entkoppelt durch einen MQTT Broker. Dieser MQTT Broker ist dafür verantwortlich, eine Nachricht den richtigen Empfängern zuzustellen, und er verwaltet die einzelnen verbundenen Clients. Der Broker ist in der Lage, eine einzelne, von einem Publisher versendete Nachricht an eine Vielzahl von Subscribern zu versenden. Es handelt sich also um eine 1:N-Kommunikation. Sowohl sendende als auch empfangende Clients bleiben ständig mittels einer stehenden TCP-Verbindung mit dem MQTT Broker verbunden, weshalb der MQTT Broker eine Nachricht im Push-Verfahren ohne Verzögerung an interessierte Clients ausliefern kann.
Bild 2 zeigt die Funktionsweise des Publish-/Subscribe-Mechanismus. Mehrere Geräte können eine Subscription am MQTT Broker erstellen und signalisieren über sogenannte Topics, an welchen Nachrichten sie jeweils interessiert sind. Der Broker kennt nun diese Abonnements (Subscriptions) der einzelnen Clients und ist in der Lage, neu ankommende Nachrichten (Publishes) direkt weiterzuleiten.
Die Adressierung der MQTT-Nachrichten erfolgt über Topics. Topics sind hierarchisch aufgebaute Strings, ähnlich wie POSIX-Dateisystempfade. Die einzelnen Hierarchiestufen werden über einen Slash („/“) getrennt. Ein Beispiel-Topic ist sensors/temperature/sensor1. Ein sendender Client benutzt einen Topic für die Nachricht in beliebiger Hierarchiestufe. Jede gesendete Nachricht enthält zwingend einen Topic. Topics müssen vorab nicht am Broker bekannt sein, sie sind vollkommen dynamisch. Wenn nun ein Subscriber am MQTT Broker einen Topic abonniert hat, ist der MQTT Broker in der Lage, die Nachricht weiterzuleiten, sobald eine Nachricht mit diesem Topic am Broker ankommt.
Um die Granularität der Abonnements für die Subscriber besser steuern zu können, existieren für die Selektion von Topics folgende Wildcards:
So könnte man mittels eines Abonnements auf sensors/# alle darunterliegenden Topics abonnieren. Es würden also alle darunterliegenden Topics wie z.B. sensors/temperature, aber auch sensors/humidity/sensor1 abonniert werden.
Mittels der Single-Level Wildcard könnte man eine ganze Hierarchieebene selektieren. Auf die Subscription sensors/+/sensor1 würden z.B. sensors/temperature/sensor1 und sensors/humidity/sensor1 greifen.
Es ist ersichtlich, dass der MQTT Broker das Herzstück der Kommunikation bei MQTT ist. Deshalb ist es wichtig, dass der MQTT Broker die Anforderungen eines Anwendungsfalles erfüllen kann. Neben der Performance spielen oft auch Kriterien wie Sicherheitsmerkmale und die Skalierung des Brokers eine Rolle.
Es gibt eine Fülle an MQTT Brokern, von einbettbaren Open Source Brokern wie etwa Mosquitto (mosquitto.org) bis zu kommerziellen MQTT Brokern wie HiveMQ (www.hivemq.com), welche bis zu mehreren Millionen MQTT Clients
in einem Cluster vernetzen können. Ein Grundprinzip von MQTT ist die Einfachheit der Implementierung am Client. Es existieren daher viele MQTT-Client-Bibliotheken in unterschiedlichen Programmiersprachen und für unterschiedliche Plattformen. Das Projekt Eclipse Paho (www.eclipse.org/paho) bietet viele frei verfügbare MQTT-Client-Implementierungen an, beispielsweise C (sowohl für Embedded als auch für Windows/Linux), C++, Java, Lua, C# und Go. Auch Eigenentwicklungen von MQTT Clients findet man häufig in Projekten, da die Implementierung vergleichsweise einfach vonstatten geht und u.U. nicht alle MQTT Features für einen spezifischen Anwendungsfall benötigt werden.