An introduction to ZeroMQ

Good read, but the ending is uninformed:<p><i>Lets say you want to create some new sort of database because Redis, Cassandra, TokyoTyrant, Postgres, MongoDB, DabbleDB, CouchDB, HBase, etc. just don’t serve your needs that well. You create an amazing in memory tree representation for your data and have a blazing fast indexer. Now all you need is some sort of messaging layer such that different clients can talk to your server. Preferably implemented in different programming language and with clustering capabilities. You could of course create such a messaging framework all by yourself, but that is a lot of hard work.<p>A simple solution is to just implement your database as a ZeroMQ server and pick a message protocol (fe JSON). As you have seen by now, implementing such functionality with ZeroMQ is really easy and on top of this you will get almost instant scalability because of the way ZeroMQ can route messages.</i><p>Interesting scalability and replication problems are not solved by (this kind of) routing. Putting it another way, problems that are solved at this level are also solved by running a bunch of Memcache servers where the standard client already includes a kind of sharding logic.

ZeroMQ works very well in combination with Apache Zookeeper [1] for service discovery and coordination.<p>Zookeeper is often overlooked because of the general aura of bloat surrounding Hadoop. It's actually quite lean, and now has python bindings, courtesy of Cloudera.<p>[1] <a href="http://hadoop.apache.org/zookeeper" rel="nofollow">http://hadoop.apache.org/zookeeper</a>

Some things in there seem to be contradictory. In particular, there's a claim about being brokerless:<p><i>ZeroMQ follows a brokerless design so that there is no single point of failure.</i><p>But then there's this: <i>ZeroMQ greatly simplifies this pattern by allowing you to have a single socket connect to multiple end points.</i><p>How does that work? Seems like a cognitive disconnect to me. AFAIK, a single socket can only connect at exactly two end-points (one being a client, the other being a server). Right? Sounds like a broker would be connecting that one socket up to multiple end points...<p>Maybe there's no CENTRAL broker, but certainly (at least in some configurations and uses), it sounds like there's an intermediary process involved in the communication.

Anyone know if 0MQ (or similar) can have multiple publishers send to the same queue? Some context:<p>- I currently have an app where users submit content to a single machine, which is then queued (using Python's inbuilt Queue object), and processed and displayed by threads that run on the queue.<p>- In future, I've been thinking about using a network queue to easily publish from a single source to multiple display servers, with a load balancer in between them. This neatly handles my 'view only' users.<p>- But what about if I wanted to allow users to submit from any server, ie, spreading the load for contributing users as well?<p>I'm guess I'm looking for a multiple publisher / multiple subscriber queue. Does anyone know if they exist?

Very interesting. Eagerly waiting for Node.js bindings.

Great, had been meaning to take a look at ZeroMQ and this was a good 20min read/synopsis. Thanks.

I stopped reading this article because he misspelt "once" as "ones".