Usage Instructions for MQTT Protocol Supported by RabbitMQ

Recent Pages

Usage Instructions for MQTT Protocol Supported by RabbitMQ

Last updated: 2024-09-10 14:38:07

Overview
MQTT is a widely used protocol for Internet of Things (IoT) applications. RabbitMQ, a popular open-source message queue product based on the AMQP 0.9.1 protocol, supports MQTT through plugins. This allows RabbitMQ clusters to easily support the MQTT protocol, facilitating its use in IoT and other business scenarios.
Community reference documentation:
1. The MQTT protocol supported in RabbitMQ versions earlier than 3.11:  MQTT Plugin — RabbitMQ
2. The Native MQTT protocol supported in RabbitMQ 3.12:  Serving Millions of Clients with Native MQTT | RabbitMQ - Blog
Directions
Step 1: Purchasing or Self-Building a RabbitMQ Cluster
Directly purchase a RabbitMQ cluster in the cloud. Buy Now.
Or build your own RabbitMQ cluster. For detailed instructions, see Downloading and Installing RabbitMQ — RabbitMQ.
Step 2: Enabling the MQTT Plugin
Enable the MQTT plugin by executing the following command on the cluster node:
sudo rabbitmq-plugins enable rabbitmq_mqtt
The RabbitMQ plugin management feature on Tencent Cloud is under development. Currently, you can enable the MQTT plugin and network connectivity by submitting a ticket.
After enabling the MQTT plugin, you can see the newly added port 1883 in the console:
﻿
Step 3: Verifying the Availability of MQTT
Download the commonly used mqttx (MQTTX: A Full-Featured MQTT Client Tool) for verification.
1. Create a connection and fill in the address and port. Use the RabbitMQ username and password for the username and password fields.
﻿
2. Create a subscription to subscribe to the messages of the testtopic/# topic.
﻿
3. Check the RabbitMQ queue status, and you can see that each subscription will add a queue to RabbitMQ.
﻿
4. Verify message sending and receiving by sending a message to testtopic/123456 and confirming that it is received through the subscription.
﻿
5. View the RabbitMQ monitoring to see that the recent message sending and receiving activity for the queue has been recorded.
﻿
6. Verify the interoperability of MQTT upstream messages and RabbitMQ messages. Messages sent by MQTT can also be routed to a standard queue and consumed by RabbitMQ downstream applications.
﻿
﻿
7. Verify the interoperability of downstream messages between RabbitMQ and MQTT, where messages can be sent from RabbitMQ and subscribed to by MQTT.
﻿
﻿
8. Summary: Through the above verification, it can be confirmed that the RabbitMQ's MQTT plugin supports normal MQTT message sending and receiving, processes MQTT upstream messages to applications, allows applications to send MQTT downstream messages to subscriptions, and provides comprehensive monitoring.
How It Works
In versions earlier than 3.11, MQTT messages are converted to AMQP protocol to achieve MQTT message sending and receiving.
﻿
In version 3.12 and later, the MQTT protocol is processed natively without AMQP protocol conversion, theoretically achieving better performance.
﻿
Notes
It is recommended to use stable versions such as 3.8.x or 3.11.x, which are free of known bugs.
Version 3.12.x is a newly released version. MQTT found that monitoring was not stable during the verification process for 3.12.x. Therefore, it is not recommended to use version 3.12 in production environments.
Currently, the mainstream MQTT v3 and v3.1 versions are supported, but v5 is not yet supported. RabbitMQ Expected to Support MQTT in Version 3.13 and Later.
The MQTT protocol uses / to separate topics, while the AMQP protocol uses . to separate topics (Routingkey). This difference is automatically processed during protocol conversion, but be aware of this when using the application.
Anonymous connections or no login credentials are not recommended for MQTT, as the AMQP protocol automatically converts them to the default user, either guest or mqtt.default_user, making permission control difficult.
Regarding subscription persistence, pay attention to the mapping of MQTT and AMQP queue persistence.
Transient clients that use transient (non-persistent) messages
Stateful clients that use durable subscriptions (non-clean sessions, QoS1) should prefer using mirrored queues instead of Quorum Queues, as Quorum requires at least three nodes, and the stability of the new feature is yet to be verified. It is currently not recommended for use.
It is recommend to use image queues instead of Quorum Queues, as Quorum requires at least three nodes, and the stability of the new feature is yet to be verified. It is currently not recommended for use.
﻿