消息队列各种比较

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