|Re: [mosquitto-dev] A non-centralize Mosquitto cluster design.|
I am Jianhui who is the sponsor of this topic, and this is my new account since my previous mailbox cannot receive eclipse mail list immediately.
Certainly the cluster could be created by bridge, but as I sad that centralized architecture strongly depend on the high availability of the central(bridge) node, we tried to use the standby bridges, but it often crashed due to the heavy message forwarding.
Also, another scheme is that the bridge can be configured for each node as a non-centralized architecture, but the static topic forward strategy inside each bridge is not flexible. So whatever extend the bridge feature or create a new cluster, the key is non-centralize, balance the forwarding load to each of the node.
Currently my cluster can work properly while Pub & Sub on different nodes. Later I would like to give the performance testing reports and the benchmarks about this cluster. As you said, really a huge modification, a lot of work is waiting for me:)
I guess creating cluster features by extending current bridge is a good idea. See also: https://dev.eclipse.org/mhonarc/lists/mosquitto-dev/msg01590.html Could you show the outcome by some performance benchmarks if you already had? If the outcome is effective, worth to proceed. Then you should make a plan to divide the whole creation into some steps and make each PR in order to accept by committers step by step. Because your creation is too huge to confirm the properly. The core features of broadcasting SUB and Traffic cycle avoidance as extending bridge may be the first PR. Further performance improvement and supporting persistence inter clustering nodes are may be laters. Regards, Tatsuzo 2017-12-02 0:30 GMT+09:00 èåè <hui6075@xxxxxxx>: > Hi all, > I am try to renovation my MQTT cluster which use Mosquitto as the broker, > our Subscriber and Publisher are intelligent household electrical appliances > and Mobile phones, the actual scenario is that each appliances subscribe > some topics after network configuration as Subscriber, and almost no longger > subscriber for new topics. As Publisher, the appliances may report its > status each several minutes. > I have deployed two cluster schemes, > 1. use Mosquitto bridge. But the bridge often crash due to heavy traffic; > 2. each appliance push message to a webserver, and the webserver broadcast > the PUBLISH messages to each nodes in the cluster, this is also not a good > cluster design. > > So I am thinking for a new kind of Mosquitto cluster architecture, which > is non-centralization, means there is no leader node inside the cluster. > Attached is the architecture design presentation and implemented code, > could you give me some advise? > P.S my codes are wrapped with #ifdef WITH_EPOLL_V2 and #ifdef WITH_CLUSTER, > currently only implement on raw MQTT, I means without websockets and > TLS/SSL. > > > > > > _______________________________________________ > mosquitto-dev mailing list > mosquitto-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
Back to the top