消息隊列各類比較

時間 2019-11-17

標籤消息隊列各類比較简体版

原文原文鏈接

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

最近的工做須要用到MessageQueue來作「任務分發」，本身寫了一個簡單的，可是感受不夠滿意。主要仍是感受消息隊列持久化要作的好很難，還有各類異常狀況等等，短期開發一個，挑戰很大，仍是找一個開源的實現吧。html

先是找到了RabbitMQ，是erlang寫的，而咱們的系統是用Go寫的，目前它尚未Go的綁定，部署系統的時候也要裝erlang虛擬機。考察了以後決定放棄。java

而後是最近大名鼎鼎的ZeroMQ，第一次據說是在雲風大哥的博客上（http://blog.codingnow.com/2011/02/zeromq_message_patterns.html），我後來在尚未用它寫代碼以前就分析過它的源碼了（http://blog.csdn.net/archimedes_zht/article/details/7342937，http://www.zeromq.org/docs:omq-2-1-class-diagram）。:Dnode

分析代碼的時候就知道它沒有分發任務、執行任務時候的各類確認，任務的持久化以防止任務丟失。不過ZeroMQ能夠把內存中放不下的消息先寫到磁盤上去，而後再讀進內存（見swap_t類）。此次再大體看了下它的文檔，能夠確認它的名字雖然是MQ，可是它提倡的是「結構化網絡編程」，它創建了很是靈活的編寫網絡程序的基礎設施，能夠用在各類場合，不過這些場合都須要你本身利用它提供的基礎設施來定製（好比我如今急切須要的各類任務分發相關的特性）。目前知道的是它能夠建立一個queue的device。不過這個目前和個人「任務分發」需求相差很遠。之後有空再研究這個精彩的、雄心勃勃的項目吧。ios

而後是Gearman（http://gearman.org/），它是專門作任務分發的。任務能夠分爲前臺任務（同步任務）和後臺任務（異步任務），並且提供了任務的持久化機制（配置一個數據庫就好了，支持MySQL，Sqlite3等），很是符合個人胃口。:) 並且 mikespook大俠已經提供好了Gearman協議的Golang實現（http://www.mikespook.com/2011/05/go-%E8%AF%AD%E8%A8%80%E7%9A%84-gearman-api/）代碼也實現的很是漂亮，學習了。並且我據說有Gearman這個好東東也是看了mikespook大俠的Go語言介紹才知道的（http://ecug.googlecode.com/svn/trunk/ecug-con/2011/mikespook/）。git

我我的以爲Gearman的文檔最值得看的就是它的協議交互了（http://gearman.org/index.php?id=protocol ），另外就是它的C接口使用（http://gearman.org/docs/dev/ ），分爲Client和Worker兩部分。github

不過在下載安裝Gearman的時候，發現居然要先裝Boost，唉。。。
另外若是Gearman仍然是C開發的就行了，爲何要轉向C++呢。。。搞不懂，不明白。。 golang

最後以查找資料的時候，國外牛人對各類「MQ」的總結結束。redis

RabbitMQ、ZeroMq和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 are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are 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 are 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 but contrary to RabbitMQ, you’ll have to implement most of them yourself by combining various pieces of the framework (e.g : sockets and devices). Zmq is very flexible but you’ll have to study the 80 pages or so of the guide (which I recommend reading for anybody writing 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 be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. It’s the Swiss army knife of messaging :-).

Finally, all 3 products:
(1)have client apis for the most common languages (C++, Java, .Net, Python, Php, Ruby, …)
(2)have strong documentation
(3)are actively supported

Gearman與RabbitMQ的比較：

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

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

一篇文章：

常見的開源消息系統——網站公告、通知、消息的實現方式

消息系統的做用：異步處理、削減峯值、減小組件之間的耦合。

選擇消息系統根據業務須要須要考慮如下幾個方面：