There are things you just cannot do with AMQP and thus RabbitMQ. The main one, and why we originally started ZeroMQ, was multicast from publishers to subscribers. How else can you get message rates of millions per second?
ZeroMQ (and Nano and the many similar efforts that have come to life since we started) gives every process the same capability. Your laptop can talk directly to ten thousand peers, and do it rapidly.
We do have a broker, Malamute, which works nicely for various patterns. I use this in lots of projects. However not in the conventional sense of starting a process on a box somewhere. I use Malamute as an actor thread, to coordinate events and workload between other actor threads, in a single process.
ZeroMQ makes this kind of scale magic quite easy. Take a look at the CZMQ library and you'll see how wise use of ZeroMQ transforms even an old language like C. Thread-to-thread messages work the same way as process-to-process messages. You can't even think of such things using AMQP.
It does change the way you build distributed systems.
I hate Celery and I hate RabbitMQ because it was so difficult to get stuff working the way I wanted which makes me wonder if it would've been better if I just wrote my own simple job queue.
Last I checked, ZeroMQ is more of a "low-level" library/framework that provides easy-paths to more higher-level functionality that would be comparable with what you'd expect from a standard message queuing system.
Anyone got a different take from it? I only did the tutorials quite a while back.
For example, the Mongrel2 web server uses ZeroMQ to drive backend handlers. You probably wouldn't dream of transporting HTTP requests and responses over a brokered message queue, but ZeroMQ is different since it's "just sockets".
It really requires that you can eat messages off as quick as you can put them on the queue, or else it slows down -- which means you can't pull them off as quickly, and then things basically get to "cascade failure" type problems.
Maybe others have other experiences - Rabbit is fast, but I'd probably evaluate other options if you want your queue to actually, well, queue.
recommended read: http://zeromq.org/topics:omq-is-just-sockets
"We investigated different solutions to find something suitable for our needs. We tried different message brokers (RabbitMQ, ActiveMQ Apollo, Kafka), but failed to reach a low and predictable latency with any of them."