消息隊列各種比較

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

最近的工作需要用到MessageQueue來做“任務分發”，自己寫了一個簡單的，但是感覺不夠滿意。主要還是感覺消息隊列持久化要做的好很難，還有各種異常情況等等，短時間開發一個，挑戰很大，還是找一個開源的實現吧。

先是找到了RabbitMQ，是erlang寫的，而我們的系統是用Go寫的，目前它還沒有Go的綁定，部署系統的時候也要裝erlang虛擬機。考察了之后決定放棄。

然后是最近大名鼎鼎的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）。:D

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

然后是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/）。

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

不過在下載安裝Gearman的時候，發現竟然要先裝Boost，唉。。。 
另外如果Gearman仍然是C開發的就好了，為什么要轉向C++呢。。。搞不懂，不明白。。 

最后以查找資料的時候，國外牛人對各種“MQ”的總結結束。

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.

 

一篇文章：

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

消息系統的作用：異步處理、削減峰值、減少組件之間的耦合。

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

1. 是否持久化
2. 吞吐能力
3. 高可用
4. 分布式擴展能力
5. 兼容現有協議
6. 易於維護
7. 其他，如消息丟失和重復的處理
8. 避免單點故障
9. 負載均衡

常見消息系統協議:

1. STOMP
2. AMQP
3. 類似 MEMCACHE 的協議
4. HTTP
5. 自定格式

下述1、2 是不錯的可選開源組件：

1. Kafka/MetaQ: 廣泛用於 Linkedin 內部 (類似有 Java 版本的國產 MetaQ)

由於優先考慮吞吐，更加適合大數據量的消息收集和處理，比如日志分析、用戶行為信息實時報表、集群狀態信息收集和分析。

1. 優先考慮持久化的設計,依靠 page cache 管理內存
2. 高吞吐 112MB/s 11K msgs/s (比 beanstalkd >70x 吞吐能力)
3. 支持異步復制
4. 高可用、基於 Zookeeper 的集群設計、支持消費者失效后重新負載均衡
5. Kafka 提供 PHP 類庫
6. 支持 ganglia JMX 監控
7. 需要策略避免重復消息, 消費者更新 Zookeeper 的 offset 的方式 (MetaQ 已經提供了幾種方式避免消息重復)
8. MetaQ 提供 HTTP 接口

https://kafka.apache.org/

http://metaq.taobao.org/

2. NSQ – Golang

無中心設計、節點自動注冊和發現。可以考慮作為內部通訊框架的基礎。

* 追求簡單部署
* 追求高可用、避免單點故障、無中心設計
* 確保消息送達
* 生產者消費者自動發現、消費者連接所有生產者、向消費者推的模式
* 提供 HTTP 接口

https://github.com/bitly/nsq

3. Beanstalkd

1. 支持持久化 binlog 設計，重啟消息不丟失
2. 一般
3. 無高可用設計
4. 和 memcached 一樣的分布式擴展方式
5. 各種類庫
6. 有 Web 管理工具
7. 支持同步調用，等待返回
8. 只有類似 Memcache TCP ASCII 協議, 單文件部署
9. 支持消息優先級
10. 9K jobs/s 入隊列 5K jobs/s 出隊列
11. 單點故障
12. 無主從同步復制機制
13. 最好單機多實例部署

http://kr.github.io/beanstalkd/

4. Redis

需要自己封裝 Pub/Sub

• 基於 Redis 的復制高可用

其他常見開源消息系統：

ZeroMQ: 輕量級基礎消息庫

只適合不需要持久化的場景、需要自己封裝

1. 不支持持久化，只提供消息分發, 性能最好
2. 無 Broker 設計, 無中心故障

RabbitMQ

• 2500 job/s 入隊列 1300 job/s 出隊列
• 適合小消息
• 分布式無單點設計
• 底層為 Erlang 實現
  有評論: RabbitMQ could not enqueue/dequeue fast enough.

RESTMQ

http://restmq.com/

MemcacheQ

http://memcachedb.org/memcacheq/

HTTPSQS

https://code.google.com/p/httpsqs/

Gearman

http://gearman.org/presentations
https://code.google.com/p/shard-query/

Kestrel

http://robey.github.io/kestrel/
http://robey.github.io/kestrel/docs/guide.html

HornetQ

性能差不考慮

Resque

3800 jobs/s 入隊列 300 jobs/s 出隊列
https://github.com/blog/542-introducing-resque
基於 Redis 的消息隊列

Starling

https://github.com/starling/starling

SquirrelMQ

https://code.google.com/p/squirrel-message-queue/

Sparrow – Ruby

https://code.google.com/p/sparrow/

Apache ActiveMQ

ActiveMQ crashed constantly under load.

STOMP HTTP 協議

http://stomp.github.io/stomp-specification-1.2.html