Blog.csdn.net/hui6075/art…

www.cnblogs.com/lexiaofei/p…

Blog.csdn.net/z729685731/…

Blog.csdn.net/yuhaiyang45…

Mosquitot Bridge Mode Mosquitot Cluster mode

Introduction to the MQTT protocol

MQTT is a set of application-layer instant communication protocols defined by IBM for environments such as the Internet of Things, which provide a subscription/publish approach through messaging middleware to decouple communication between different devices through “topics”.

There are similar protocols such as XMPP and COAP, but MQTT protocol has low requirements on equipment processing capacity and network environment due to its few signaling types, little control information and high information carrying rate. Imagine asking a 200MHz embedded module with 64K memory to parse HTTP/JASON/XML strings. The next packet may arrive before the packet is parsed. Of course, there are also many people take MQTT as android push protocol, which can also improve user experience very much. For example, the retention message in MQTT protocol can allow the mobile phone to receive some messages released by the system or other devices before boot up.

Often referred to as message-oriented brokers, there are mosquito-enabled BROKERS out there, including Mosquito-based C-based Brokers, Erlang-based EMQ, RabbitMQ+ plug-ins, Java-based ActiveMQ, and even Node.js based Mosca. I tried Mosquitto and RabbitMQ, Mosquitto completely realize all the MQTT protocol content, and the RabbitMQ support for MQTT is not perfect, such as not support QoS = 2 messages, and retain the message. In addition, EMQ developed by Chinese is also an excellent MQTT broker that supports clustering and message persistence.

Mosquito-bridge mode

Mosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquitmosquito Mosquito.conf can also be used to connect multiple brokers with mosquito.conf if traffic is too heavy. Usually, a single broker should be chosen as a bridge node to add the option to the mosquito.conf file:

Connection bridge1 address 192.168.1.102:1883 Topic # both 0

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

Bridge1 /bridge2 is the name given to other brokers, the address is the IP address and port of other brokers, and topic specifies the message topic that is allowed to pass between the local broker and the other broker. With #, all topic messages are delivered. Both /in/out refers to the allowed message directions. In means that the topic message can be forwarded only from the other broker to the local broker, not from the local broker to the other broker. If a local broker subscribes to the /sensor/ Temperature theme, the local client receives /sensor/ Temperature theme messages posted to the other broker, and does not receive them.

From the above introduction, it can be seen that topic configuration in Bridge mode is very inflexible. In particular, in some scenarios, the communication between the message publishing client and subscription client uses MAC address and UUID as the topic name, and it is impossible to manually configure each pair of publish/subscribe devices.

Mosquito-cluster Mode

Mosquitos also has mosquitos cluster implementation based on secondary development.

Github.com/hui6075/mos…

The clustering approach is dynamic subscription, where each broker is both publisher and subscriber. For topics subscribed by clients connected to the local broker, the local broker subscribes to other brokers in the cluster, so there is no need to dynamically configure a topic filter beforehand. In addition, all brokers in the cluster are on an equal level, so there is no single point of failure. It’s also pretty simple to configure, with mosquito.conf for 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

In the compilation of mosquitto config. Mk WITH_BRIDGE commented out, put the WITH_CLUSTER: = yes uncomment, then make && make install mosquitto installation, and in all the machine start mosquitto can.

Functional testing:

Subscribe to the topic “clusterMsg” on host 1, publish the message with the topic “clusterMsg” on host 2, and host 1 can receive the message.

Benchmark:

The overall throughput of the cluster was tested with 1 broker, 2 brokers, 3 brokers, 4 brokers, and 9 brokers respectively. The overall throughput increased gradually from 1 broker to 3 brokers, with an increase coefficient of about 0.8. Overall throughput stops growing when brokers exceed 3 due to pressure tool bottlenecks.

Test parameter description: The message length is fixed at 1000 bytes. N10k indicates that each client sends 10K messages. C100 indicates that a total of 100 clients.

Mosquitto cluster@github for more detailed performance test reports on the principles of the cluster, see mosquitto project readme.md.