Scalability and Topic Limits

EMQX does not impose a hard limit on the number of topics. You can scale topics as needed with minimal impact on performance, provided the system has sufficient memory and CPU resources.

Data Storage in Open Source vs. Enterprise

The Open Source version of EMQX does not include built-in data persistence features. To store message data, you must either upgrade to the Enterprise Edition or implement an external solution using Webhooks or a separate MQTT subscriber to write data into a database (e.g., MySQL, Redis).

Comparison with IoT Network Protocols

EMQX is an application-layer MQTT broker running on top of the TCP/IP stack. In contrast, NB-IoT and LoRaWAN operate at the physical and link layers. While NB-IoT and LoRaWAN handle signal transmission, EMQX manages the high-level messaging protocol that runs over the resulting data connection.

MQTT vs. HTTP for IoT Applications

MQTT is optimized for IoT, whereas HTTP is a stateless protocol typically using short-lived connections. Key advantages of MQTT include:

• Real-time Push: Unlike HTTP polling, MQTT enables the server to push data to devices instantly over persistent connecsions.
• Efficiency: MQTT headers are significantly smaller. Research shows MQTT uses up to 50 times less bandwidth and consumes substantially less battery power compared to HTTP.
• Connectivity Monitoring: MQTT includes built-in Keep-Alive mechanisms to detect dead connections at a lower cost than HTTP heartbeats.
• Quality of Service: Developers can choose QoS levels (0, 1, 2) to balance reliability and overhead.

Message Queuing (mqueue)

EMQX uses an internal queue called mqueue to buffer messages for clients with persistent sessions (Clean Session set to false). If a client disconnects, EMQX continues to receive messages on its behalf and stores them in RAM. When the client reconnects, the messages are delivered.

Configuration parameters include:

• mqtt.mqueue_store_qos0: Determines if QoS 0 messages are buffered.
• mqtt.max_mqueue_len: Sets the maximum number of buffered messages per session. Note: Setting this to 0 (unlimited) can lead to Out-Of-Memory (OOM) errors.

Concurrency and High Availability

EMQX achieves massive concurrency (up to 5 million connections per node) by leveraging the Erlang/OTP platform. It utilizes an asynchronous architecture and splits the system into control and message planes. Clustering multiple nodes ensures high availability; if one node fails, others continue to serve clients without interruption.

Message Delivery Ordering

EMQX guarantees that messages published to the same topic by a single client are delivered to subscribers in the order they were received. However, the order is not guaranteed for messages across different topics, as they may be processed via different routing paths.

Shared Subscriptions

Shared Subscriptions (introduced in MQTT 5.0) allow multiple clients to share the load of a single subscription. Messages sent to a shared topic are distributed among subscribers using strategies like round-robin or random selection, rather than being sent to all of them. This is ideal for high-throughput data processing tasks.

System Monitoring via $SYS Topics

System topics starting with $SYS/ provide real-time metrics. Examples include:

• $SYS/brokers: Node list.
• $SYS/broker/${node}/stats/connections/count: Active connection count.
• $SYS/brokers/${node}/clients/${clientid}/connected: Connection events.

Troubleshooting Common Startup Issues

OpenSSL Compatibility

If EMQX fails to start with a crypto application error, check OpenSSL dependencies using ldd (Linux) or otool (macOS):

# Linux check
ldd lib/crypto-*/priv/lib/crypto.so

# macOS check
otool -L lib/crypto-*/priv/lib/crypto.so

If libcrypto.so is missing, ensure OpenSSL 1.1.1+ is installed and linked correctly.

Missing Dependencies

On some systems, libatomic is required. Install it via your package manager:

sudo yum install libatomic  # RHEL/CentOS
sudo apt install libatomic  # Ubuntu/Debian

Connection and SSL Troubleshooting

When SSL/TLS handshakes fail, check the logs for these keywords:

• certificate_expired: The server or client certificate has passed its validity date.
• no_suitable_cipher: Mismatch between the ciphers supported by the client and the server.
• unknown_ca: The Root CA is missing or incorrect. In mutual TLS, CLIENT ALERT indicates the client rejected the server, while SERVER ALERT indicates the server rejected the client.

Disconnection Analysis

You can inspect disconnection statistics via the CLI:

emqx ctl listeners

Common shutdown_count reasons include:

• keepalive_timeout: No PINGREQ received from the client.
• tcp_closed: The client terminated the socket without a DISCONNECT packet.
• takeovered: A new client with the same ClientID connected, replacing the old one.
• kicked: The client was removed via the Dashboard or API.

Security and Access Control (ACL)

To restrict specific topics to certain clients, use Access Control Lists (ACL). Disable anonymous access in emqx.conf first:

# emqx.conf
mqtt.allow_anonymous = false
mqtt.acl_nomatch = deny

Configure rules in etc/acl.conf or a database:

%% Allow 'admin_user' to subscribe to all system topics
{allow, {user, "admin_user"}, subscribe, ["$SYS/#"]}.

Integrating with Kafka

The Enterprise Edition supports bridging messages to Kafka. This can be synchronous (waiting for Kafka's ACK before sending MQTT ACK) or asynchronous (immediate MQTT ACK). If Kafka is unavailable, EMQX can cache messages in memory or on disk depending on the version and configuration.

Deployment Recommendations

For production, use a cluster behind a Load Balancer (LB) like HAProxy or Nginx. It is highly recommended to terminate TLS at the Load Balencer level (SSL Offloading). This reduces the CPU load on EMQX nodes and simplifies certificate management.

Resetting Dashboard Credentials

If you lose access to the Dashboard, reset the admin password using the CLI:

emqx ctl admin <username> <new_password>