Message Queuing various comparisons

http://blog.csdn.net/archimedes_zht/article/details/7401210

Recent work needs to use the MessageQueue to do "task distribution", wrote a simple, but not satisfied with the feeling. The main feeling is that message queue persistence to do is very difficult, there are all kinds of anomalies and so on, a short time to develop a, a great challenge, or find an open source implementation of it.

First we found the RABBITMQ, which was written by Erlang, and our system was written with go, and currently it has no go bindings, and the Erlang virtual machine is installed when the system is deployed. After examining the decision to give up.

Then is the recent famous zeromq, first heard is in the cloud Wind Brother's blog (http://blog.codingnow.com/2011/02/zeromq_message_ patterns.html), I later analyzed its source code before writing it with it (http://blog.csdn.net/archimedes_zht/article/details/7342937,http:// Www.zeromq.org/docs:omq-2-1-class-diagram). :D

When you parse the code, you know that it has no distribution tasks, various confirmations during the execution of tasks, and persistence of tasks to prevent task loss. However, ZEROMQ can write the messages that are not in memory to disk first, and then read them into memory (see swap_t Class). This time, I took a look at its documentation, confirming that its name is MQ, but it advocates "structured network programming," which creates a very flexible infrastructure to write network programs that can be used in a variety of situations, These occasions, however, require you to use the infrastructure that it provides (for example, the various tasks that I urgently need to distribute related features). What is known now is that it can create a queue's device. But this is a far cry from my "mission distribution" requirements. Study this wonderful, ambitious project later.

Then there is Gearman (http://gearman.org/), which is dedicated to the task of distributing. Tasks can be divided into foreground tasks (synchronous tasks) and background tasks (asynchronous tasks), and provide a persistence mechanism for the task (configure a database on the line, support MYSQl,sqlite3, etc.), very much in line with my appetite. :) And Mikespook has provided a good Gearman protocol Golang implementation (http://www.mikespook.com/2011/05/go-%e8%af%ad%e8%a8%80%e7%9a%84- gearman-api/) code is also implemented very beautiful, learned. And I heard that there are gearman this good thing is also seen Mikespook Warrior's go language introduction just Know (http://ecug.googlecode.com/svn/trunk/ecug-con/2011/mikespook/).

I personally think that Gearman's document is most worth seeing is its protocol interaction (HTTP://GEARMAN.ORG/INDEX.PHP?ID=PROTOCOL), the other is its C interface use (http://gearman.org/docs/ dev/), divided into two parts: client and worker.

However, when downloading and installing Gearman, I found that we should install boost first, alas ...
In addition, if Gearman is still C developed, why turn to C + + ... Do not understand, do not understand.

Finally, in order to find information, foreign cattle people on the various "MQ" Summary of the end.

Comparison of RabbitMQ, ZEROMQ and ACTIVEMQ:

RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache qpid). Therefore, it implements a broker architecture, meaning that messages is queued on a central node before being sent to CL Ients. This approach makes RabbitMQ-very easy-to-use and deploy, because-advanced scenarios-like routing, load Balancing or Persi Stent Message Queuing is supported in just a few lines of code. However, it also makes it less scalable and "slower" because the central node adds latency and message envelopes is quite Big.

ZeroMq is a very lightweight messaging system specially designed for high throughput/low latency scenarios like the one You can find in the financial world. ZMQ supports many advanced messaging scenarios it contrary to RabbitMQ and you'll have to implement most of the them yourself by Combining various pieces of the framework (E.g:sockets and devices). ZMQ is very flexible and you'll have to study the pages or so in the The Guide (which I recommend reading for anybody Writi NG Distributed System, even if you don ' t use ZMQ) before being able to do anything more complicated that sending messages Between 2 peers.

ActiveMQ is in the middle ground. Like ZMQ, it can is deployed with both broker and peer topologies. Like RabbitMQ, it's easier to implement advanced scenarios and usually at the cost of raw performance. It ' s The Swiss Army Knife of messaging:-).

Finally, all 3 products:
(1) The client APIs for the most common languages (c + +, Java,. Net, Python, PHP, Ruby, ...)
(2) Strong documentation
(3) is actively supported

Comparison of Gearman and RABBITMQ:

I would say that Gearman is better for queuing "jobs" and RabbitMQ are better for queuing "data". Of course, they was both really the same thing, but the the-the-the-the-it works out for me was that if you were trying to "fan out" wor K-to-be-done, and the-workers can work independently, Gearman is the better-to-do it. But if you were trying to feed data from a lot of sources-to-fewer data consumers, RabbitMQ is the better solution.

The history of RabbitMQ, as something. Allowed Twitter to take bursty loads of messages, and feeds them into crusty old SMS gateways that could keep only one connection open, were rate limited, and didnt has retries, is illustrative of the Kind of problems that RabbitMQ are good at solving.

Message Queuing various comparisons