This works well if you just have a cloud but gets hard when you have parts of the clusters at different locations you end up have clusters split into 2.. which then need to come together again.
Ben On Thu, Mar 17, 2016 at 7:18 PM, Pieter Hintjens <[email protected]> wrote: > Hi Arnaud, > > We were working on something similar, which was to elect one Malamute > instance in a cluster as leader and then tell clients where it was. It > is a nice first step to making hot-hot clustering. > > -Pieter Yes exactly the load balancing / fall over problem is commonly done but many people use tcp/ip messaging with complex architectures , remote fail over with multiple paths etc .. Then you get scale issues , you don't want to send subscription everywhere because your matching time becomes horrendous , there is quite a bit of theory on this . Its certainly the next level, On Fri, Mar 18, 2016 at 7:21 AM, Pieter Hintjens <[email protected]> wrote: > I think the difficulty is that a cluster of brokers usually means more > than backup or load balancing; it means federation of some kind. > Imagine local clients talking IPC to brokers that interconnect over > TCP. This allows for very thin local client stacks (single threaded > IPC does not need a full ZeroMQ). Brokers then need to interconnect > and trade subscriptions and streams (optimally, since most traffic is > local to local and never needs to cross the network). > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
