Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The two approaches are very different. RabbitMQ centralizes and uses a fairly heavy asymmetric protocol (that I originally designed, so I know this pretty well), which makes the server a major hub, and clients rather stupid and slow.

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 want to use ZeroMQ but stuck with RabbitMQ because I am using Celery.

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.


They're fundamentally different things. For your needs, how about rq?

http://python-rq.org




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: