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

[Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx>]

Hi Jianhui,

Great work! Could you prepare some benchmarks of your cluster?

Regards,
Tatsuzo


2017-12-07 22:35 GMT+09:00 zhan jianhui <hui6075@xxxxxxxxxxx>:
> Hi Osawa,
>
>   update the design slide for non-centralize cluster, now the retain msg
> seems work as well under functionality test.
>
>   i will keep working with this:)
>
>
> BRs,
>
> Jianhui
>
> ________________________________
> 发件人: mosquitto-dev-bounces@xxxxxxxxxxx <mosquitto-dev-bounces@xxxxxxxxxxx>
> 代表 Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx>
> 发送时间: 2017年12月2日 8:09:01
> 收件人: General development discussions for the mosquitto project
> 主题: Re: [mosquitto-dev] A non-centralize Mosquitto cluster design.
>
> 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
> _______________________________________________
> 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