Re: [mosquitto-dev] A non-centralize Mosquitto cluster design.

[Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx>]

Hi Jianhui,

I agree with you.
The bridge which I said includes the broadcasting pattern.I guess
extending broadcast features based on current bridge configuration and
implementation can be understood easily.

Regards,
Tatsuzo


2017-12-03 0:36 GMT+09:00 zhan jianhui <hui6075@xxxxxxxxxxx>:
> Hi Osawa,
>
> 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
>
>
>
>
> _______________________________________________
> 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