La distinction broker MQTT vs file de messages déroute de nombreuses équipes, car les deux sont des « message brokers » placés entre producteurs et consommateurs. La différence tient à la sémantique de livraison : un broker MQTT copie chaque message vers chaque abonné intéressé, immédiatement, alors qu'une file de messages conserve chaque message jusqu'à ce qu'un seul consommateur en prenne la responsabilité. Ce guide explique les deux modèles, les compare aux files de type RabbitMQ et SQS, et montre quand un broker MQTT cloud est la bonne brique.
Deux modèles de livraison
Publish/subscribe par topic (MQTT). Un éditeur envoie un message sur un topic comme plant1/line2/press4/temperature. Le broker examine tous les abonnements en cours, trouve ceux dont les filtres correspondent et livre une copie à chacun. Si cinq services sont abonnés, cinq copies partent. Si personne n'est abonné, le message est abandonné, sauf s'il est retained comme dernière valeur du topic ou mis en file dans une session persistante. Le rôle du broker est le routage, pas le stockage. Pour approfondir ce modèle, consultez le modèle publish/subscribe de MQTT.
Files point à point (RabbitMQ, SQS et similaires). Un producteur envoie un message dans une file. Le message y attend, de façon durable, jusqu'à ce qu'un consommateur le reçoive. Avec plusieurs consommateurs sur la même file, chaque message ne va qu'à l'un d'eux ; ils se disputent le travail. Le consommateur accuse réception après traitement, et s'il plante avant, le message redevient visible pour un autre consommateur. Le rôle de la file est de garantir que chaque unité de travail est effectuée une fois par quelqu'un.
En résumé : MQTT répond à « qui a besoin d'être informé ? », et une file répond à « qui va effectuer ce travail ? ».
Broker MQTT vs file de messages : comparaison
| Aspect | Broker MQTT | File de messages (type RabbitMQ, SQS) |
|---|---|---|
| Livraison | Copie à chaque abonné correspondant | Chaque message à un seul consommateur |
| Adressage | Topics hiérarchiques, jokers + et # |
Files nommées (plus exchanges et bindings dans RabbitMQ) |
| Message créé sans consommateur | Abandonné, sauf s'il est retained ou conservé pour une session persistante | Stocké jusqu'à consommation ou expiration |
| Stockage | Dernière valeur retained par topic, files de session par client | Files durables, souvent avec une longue rétention |
| Accusé de réception | QoS 1 et 2 entre client et broker | Ack du consommateur après traitement, relivraison en cas d'échec |
| Répartition du travail | Abonnements partagés dans MQTT 5 | Consommateurs concurrents natifs |
| Gestion des lettres mortes | Ne fait pas partie de MQTT | Fonctionnalité courante (dead-letter queues et exchanges) |
| Ordre | Par topic et par session client | Par file, avec des réserves en cas de relivraison |
| Mode de livraison | Push vers les clients connectés | Push (RabbitMQ) ou pull/long polling (SQS) |
| Empreinte client | Minuscule, tourne sur microcontrôleurs | SDK de classe serveur |
| Présence et état | Keep alive, Last Will, retained messages | Sans objet |
| Usage typique | Télémétrie d'appareils, commandes, état en direct, tableaux de bord | Tâches de fond, traitement des commandes, microservices découplés |
Là où les modèles se recoupent
La frontière n'est pas parfaitement nette, ce qui explique en partie la confusion.
MQTT possède deux fonctionnalités proches d'une file. Une session persistante fait que le broker met en file les messages QoS 1 et 2 pour un client pendant qu'il est hors ligne ; avec MQTT 5, on la borne par un session expiry interval. Les abonnements partagés ($share/group/filter) permettent à plusieurs clients d'un groupe de se partager les messages d'un topic, chaque message n'atteignant qu'un membre du groupe, ce qui correspond exactement au comportement de consommateurs concurrents. Lisez les abonnements partagés MQTT et la session persistante MQTT pour les détails.
Les systèmes de files, à l'inverse, proposent du pub/sub. Les exchanges fanout et topic de RabbitMQ copient un message dans plusieurs files, et les services cloud associent un topic de notification à plusieurs files pour la diffusion. Mais chaque abonné a toujours besoin de sa propre file déclarée à l'avance.
La vraie question n'est donc pas de savoir quelles fonctionnalités existent, mais quel modèle est natif. MQTT est nativement un modèle de diffusion avec des abonnements légers et dynamiques ; les files sont nativement un modèle de répartition durable du travail.
Voir la différence en deux minutes
Vous pouvez observer la diffusion sur le serveur MQTT public gratuit avec les clients mosquitto. Il est réservé aux tests et aux prototypes, jamais aux données de production ; utilisez un préfixe unique pour ne pas voir les messages des autres.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Diffusion : lancez ceci dans deux terminaux, chacun avec un client ID différent
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# Publiez cinq messages, assez lentement pour respecter la limite de débit par client
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Les deux abonnés affichent les cinq commandes. Pour obtenir un comportement de type file, il vous faut un plan de broker avec abonnements partagés, comme un broker Serverless payant sur ConnectMQ. Démarrez deux workers avec vos propres identifiants (chaque worker a besoin de son propre client ID et des identifiants correspondants, issus du portail) et publiez à nouveau :
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
Les deux workers en abonnement partagé se répartissent les messages, chacun n'en affichant qu'une partie. Arrêtez ensuite les deux workers, publiez à nouveau puis relancez-les : les commandes publiées pendant leur absence sont perdues. Seule une session persistante les aurait conservées, et encore, uniquement pour ce client et dans la limite du session expiry interval. C'est précisément ce manque que comble une vraie file.
Quand utiliser un broker MQTT
Un broker MQTT est la bonne brique lorsque :
- Les producteurs sont des appareils. Capteurs, passerelles PLC, véhicules, applications mobiles et navigateurs ont besoin de clients légers et d'une gestion tolérante des connexions.
- De nombreux consommateurs ont besoin des mêmes données. Une mesure part simultanément vers un tableau de bord, un service d'écriture dans un historian et un service d'alerte, et l'ajout d'un quatrième consommateur ne nécessite aucune modification côté producteur.
- L'état actuel compte plus que l'historique. Les retained messages fournissent instantanément la dernière valeur connue à chaque nouvel abonné.
- Vous avez besoin de présence. Le keep alive et le Last Will vous indiquent quand un appareil passe hors ligne.
- Vous devez pousser des commandes vers des appareils précis derrière du NAT ou sur des liaisons cellulaires.
Si vous découvrez les brokers, ce que fait un broker MQTT couvre les bases, et le tutoriel MQTT détaille les topics, la QoS et les sessions.
Quand utiliser une file de messages
Une file est la bonne brique lorsque :
- Chaque message est une tâche qui doit être traitée exactement une fois par un seul worker, comme générer une facture ou redimensionner une image.
- Le travail doit survivre à de longues indisponibilités des consommateurs, pendant des heures ou des jours.
- Vous avez besoin de réessais et d'une gestion des lettres mortes pour les messages qui échouent à répétition.
- Producteurs et consommateurs sont des services backend sur des réseaux fiables.
Utiliser les deux ensemble
La plupart des plateformes IoT finissent par utiliser les deux. Les appareils publient vers un broker MQTT. Un service consommateur s'abonne, généralement via un abonnement partagé pour pouvoir monter en charge, filtre le flux pour ne garder que les événements à traiter, par exemple « alarme déclenchée » ou « lot terminé », et les place comme tâches dans RabbitMQ ou SQS. La télémétrie en direct continue d'alimenter les tableaux de bord via MQTT, tandis que les workflows métier durables s'exécutent à partir de la file. L'article MQTT vs AMQP inclut un pont fonctionnel en Python.
Pour la partie MQTT, décidez si vous l'exploitez vous-même ou si vous utilisez un broker MQTT cloud. ConnectMQ est un broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS, retained messages, session expiry et, sur le plan Serverless payant, les abonnements partagés, plus l'isolation multi-tenant et des quotas par plan. C'est un broker, pas une file : il n'a pas de pont intégré vers une file, c'est donc votre service consommateur qui effectue le transfert, ce qui garde la frontière explicite.
Démarrer avec ConnectMQ
Utilisez un broker MQTT pour ce qu'il fait de mieux, la diffusion, l'état en direct et la connectivité des appareils, et associez-le à une file lorsque vous avez besoin de tâches durables. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et essayez la démonstration de diffusion et d'abonnement partagé ci-dessus sur votre propre broker privé.
Questions fréquentes
Un broker MQTT est-il une file de messages ?
Pas au sens classique. Un broker MQTT achemine des copies de chaque message vers tous les abonnés actuels, alors qu'une file stocke chaque message jusqu'à ce qu'un consommateur le traite. MQTT possède des fonctionnalités proches d'une file, mais il reste fondamentalement du pub/sub.
MQTT peut-il garantir qu'un message n'est traité qu'une seule fois ?
La QoS 2 garantit une livraison exactement une fois entre un client et le broker, pas un traitement de bout en bout. Pour un traitement unique des tâches, utilisez des consommateurs idempotents ou confiez le travail à une file de messages.
Que deviennent les messages MQTT lorsque personne n'est abonné ?
Ils sont supprimés, sauf si le message est retained, auquel cas le broker le conserve comme dernière valeur du topic, ou si une session persistante existe pour un abonné hors ligne.
Faut-il utiliser RabbitMQ ou un broker MQTT pour les appareils IoT ?
Connectez les appareils à un broker MQTT, conçu pour de nombreux clients légers et intermittents. Utilisez RabbitMQ derrière lui pour les files de travail backend si vos workflows en ont besoin.
