[zeromq-dev] Multicast and logging

Jarred Ward jarred at webriots.com
Fri Apr 16 21:24:22 CEST 2010


One observation. In a high-availability scenario where log messages need to
be persisted once to a datastore multicast is more difficult to manage IMO.
Lets say we have a 2-node cluster responsible for persisting messages to
HDFS. When both servers are receiving the same message you have to somehow
decide among the cluster who is going to persist the message. The typical
solution is an active-passive architecture. You can get creative with
message subjects to spread the load out across more clusters, but you still
need to have a active-passive gig going on to keep things HA.

The latter is the reason I see beauty in 0MQ downstream/upstream. You get
round-robin delivery to all of your subscribers. And if you add a node, that
node is going to help you scale horizontally without any of the
active-passive to worry about. Yes there are more TCP connections, but
message are only delivered once (no extra traffic) to one node in the farm
of subscribers.

A logging use case that I like is a forwarder installed on each machine in
the farm that is producing log messages. The apps on the machine communicate
log messages to the local forwarder in a pub/sub fashion. The forwarders on
all your app servers then downstream/upstream with the server farm that is
persisting to your datastore and/or analyzing messages. I see a few benefits
off the top of my head:

- if the network is congested messages queue in the local forwarder -- not
the apps
- we can continue adding persistence servers to scale horizontally as new
app servers are added (where/if the horizontal scaling breaks down I don't
know)
- multicast routing is not required in a separated network scenario

I realize that this type of subscriber has unique properties, but in this
case I think 0MQ shines without multicast.

One question I have, does 0MQ have the ability for a socket to start
dropping messages when a queue limit is reached? For example, if the
forwarder downstream socket can't communicate with an upstream socket we
don't want it to consume all the memory on the machine and start crashing
the apps...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100416/ceb408b9/attachment.html>


More information about the zeromq-dev mailing list