February 2nd, 2012
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
I have to admit, the name “ZeroMQ” was a little misleading for me. I think that’s because most other message queues are very similar: something pushes messages into a big, centralized queue, and workers pop messages off the front. ØMQ is really just a networking library. Sockets the way you want them to work. I think Zed Shaw put it best in his Pycon talk: ØMQ can replace your internal HTTP REST services. HWhaaat?!?
First, a Quick Primer
ZeroMQ is a c++ library providing asynchronous messaging over a variety of transports (inproc, IPC, TCP, OpenPGM, etc). It has bindings for over 20 languages. ØMQ has simple socket patterns that can be used together to build more complex architectures.
Request and Reply sockets are the simplest type, providing synchronous messaging between two systems.
Push and Pull sockets let you distribute messages to multiple workers. A Push socket will distribute sent messages to its Pull clients evenly.
Publish sockets broadcast messages to any Subscribe sockets that may be listening.
Dealer and Router sockets (or X_REP/X_REQ in older versions of ØMQ) handle asynchronous messaging. They require a bit of knowledge of ØMQ addressing to really grok.
When you’re designing large systems, it makes sense to break things out into smaller pieces that communicate across some common protocol. A lot of people champion the REST/JSON combo because it’s easy, it works well, and it’s available everywhere.
ØMQ is like that too. It works nearly the same in every supported language. You can use JSON, MessagePack, tagged netstrings, etc. You get cool socket types that aren’t really possible with REST (pub/sub, push/pull).
You do end up having to build your own protocol a bit. You end up losing the richness of HTTP (verbs, URIs, headers). You’re also unable to expose these services outside your private network due to some asserts in the ØMQ code.