Mqtt Brief introduction Mosquitto Bridge and cluster environment build __mosquitto

original articles such as reprint, please indicate the source (http://blog.csdn.net/hui6075/). https://blog.csdn.net/hui6075/article/details/79092318
Directory:
Introduction to MQTT protocol
Mosquitto Bridge mode
Mosquitto Cluster model

Introduction to MQTT protocol

Mqtt is a set of application-layer Instant messaging protocols, defined by IBM for the environment of things, that provide a way of subscribing/publishing through "themes" to provide decoupling of communication between different devices through the message middleware.

Similar agreements include XMPP, COAP, and so on, but the MQTT protocol is low in processing capacity and network environment because of its few signaling types, less control information and high information carrying capacity. Just imagine, let a 200MHz, 64K memory embedded module to parse Http/jason/xml string, may not wait until the data packet parsing, the next data will come, haha. Of course, there are a lot of people with Mqtt as an Android push protocol, but also very can improve the user experience, such as the MQTT protocol in the reservation message, you can get the phone to boot before the system or other devices have been released some information.

Often called message middleware as broker, there are many support Mqtt broker, open source such as Mosquitto based on C language, Erlang emq, rabbitmq+ Plug-ins, Java based ACTIVEMQ, Even based on the Node.js Mosca. I tried it myself. Mosquitto and Rabbitmq,mosquitto fully implement all the content of the MQTT protocol, and RABBITMQ support for MQTT is imperfect, such as messages that do not support qos=2 and messages that are reserved. In addition, the Chinese developed their own emq is also a very good MQTT broker, support cluster, message persistence.

Mosquitto Bridge mode

The broker used in my production environment is Mosquitto, and to be honest, Mosquitto was originally designed to run on an embedded platform, using an IO model, a timer that is simple, and usually needs to be optimized to support a business scenario with large traffic and high concurrency. And when traffic is too large, Mosquitto also supports connecting multiple broker via Bridge (bridging), typically selecting a broker as a bridge node and adding bridging options in its configuration file (mosquitto.conf):

Connection Bridge1
Address 192.168.1.102:1883
Topic # both 0

Connection Bridge2
Address 192.168.1.103:1883
Topic/sensor/temperature in 1

Where Bridge1/bridge2 is the name for other broker, the address is the IP and port of other broker, topic specifies the message subject to be passed between local broker and other broker, and all subject messages are delivered. Both/in/out refers to the allowed message direction in which the forwarding direction of this topic message can only be from the other broker to local broker, not from local broker to counterparty broker, so that if a client connects to a local broker subscription/sensor/ Temperature this topic, the local client that publishes the/sensor/temperature topic message on the other broker can also receive, and vice versa.

Through the above, you can know that the bridge mode under the topic configuration is very inflexible, especially in some scenarios the message publishing client and the Subscriber through the MAC address, UUID, etc. as the subject name to communicate, simply can not manually for each of the Publish/subscribe device configuration.

Mosquitto cluster model

Mosquitto also has a cluster implementation based on two development.

Https://github.com/hui6075/mosquitto-cluster

The cluster approach is dynamic subscriptions, where each broker is both a publisher and a subscriber, and local broker subscribes to other broker in the cluster for the subject of a client subscription to local broker, so there is no need to dynamically configure the theme filter beforehand. In addition, all the broker in the cluster is on the same footing, so there is no single point of failure. Configuration is also very simple, in the mosquitto.conf of each machine:

Node_name Node1
Node_address 192.168.1.101:1883

Node_name Node2
Node_address 192.168.1.102:1883

Node_name Node3
Node_address 192.168.1.103:1883

When compiling the Mosquitto, comment out the With_bridge in Config.mk, uncomment With_cluster:=yes, and then make && made install install Mosquitto. and start Mosquitto on all machines.

Functional testing:

On Host 1, subscribe to the subject "clustermsg", and on host 2, publish a message with the theme "Clustermsg", which can be heard on Host 1.

Benchmark

With 1 broker, 2 broker, 3 broker, 4 broker, 9 broker, test the overall throughput rate of the cluster, from 1 broker to 3 broker, the overall throughput rate is increasing. The growth factor is about 0.8, and the overall throughput rate of broker over 3 stops growing because of the bottleneck of the pressure measuring tool.

Test parameter Description: Message length fixed 1000 bytes, n10k refers to each client to send 10k messages, c100 refers to a total of 100 clients, the QoS selection is 2.

The principles of clustering and more detailed performance test reports are visible in the Mosquitto cluster@github  project readme.md.