消息队列系统对比

RabbitMQ

1. 有pub/sub功能，支持同步和异步

2. 单条消息无大小限制

3. 理论上没有消息丢失或重复投递

4. 保证消息顺序

5. 支持异步发送消息

6. 客户端支持C/C++、C#、Erlang、Java、PHP、Python、Ruby、Perl、Lisp、Haskell等很多种语言

7. 支持持久化，对queue需要指定durable=True，对message需要指定delivery_mode=2，默认是非持久化

8. 支持Message acknowledgment，将某个message发送至某个consumer后，若在收到ACK前该consumer到broker的连接断开，则 broker将该message重新发送至另一个consumer。也可关闭该特性，使用no_ack=True标志即可，默认为打开状态

9. 队列容量无限制

10. 支持AMQP协议

11. 具备一个tracer工具，用于跟踪异常情况

12. 有副本机制，无单点故障

13. 具备一个图形化的管理监控界面，以插件方式提供，使用方便

14. Erlang语言实现，我们不熟悉，代码量较多

15. 开发活跃，社区成熟，用户量很大

16. 支持事务

17. 默认以Round-Robin方式向consumer发送message，可指定为Fair dispatch方式，即一个consumer未发回ACK前不接收新的message

18. exchange的概念：direct, topic, headers and fanout。producer不是直接把message发给broker，而是经过exchange做路由处理后再发，内建4种exchange，还可 以自己编写exchange的插件，非常灵活

19. topic类型的exchange支持通配符

20. 插件架构，功能可扩展

21. 有认证和授权等安全机制

官网http://www.rabbitmq.com/

 

ActiveMQ

 1 支持pub/sub消息，接收者支持同步/异步模式。

2 消息无大小限制。

3 有网络不好，或者机器重启有丢消息或者消息重复的可能

4 消息的发送支持同步/异步。

5 客户端语言支持广泛,Java, C, C++, C#, Ruby, Perl, Python, PHP

6 支持消息持久化，多种方案选择（例如文件或者db)

7 支持集群或者主从方式，消息在主从方式中有备份，集群起负载作用。这个特性类性于mysql的多主和主从。

8 支持对消息的消费反馈确认。

9 消息的容量在无持久化时依赖于内存大小，有持久化时无限制。

10 支持多种JMS协议OpenWire,Stomp REST等，特性丰富。

11 部署和维护都比较复杂，但相关管理工具比较丰富。

12 故障切换处理比较完善。

13 水平扩展比较方便.

14 服务用Java语言，代码量大，复杂，难于维护。目前开发活跃，使用者非常广。

其它特点参考:

1 相比其它队列，性能并不是大好，尤其是开启持久化后，下降非常明显。

2 对于频繁连接的client性能处理很差，所以对于web请求中的，这种量大的短连接不太理想。

3 同事在其它业务使用中，发现其有阻塞，崩溃的现象。

官网http://activemq.apache.org/

特性总结：http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

实际作用情况:http://highscalability.com/blog/2010/5/10/sifycom-architecture-a-portal-at-3900-requests-per-second.html

 

Beanstalkd

 1 不支持pub/sub功能。

2 server启动时指定单条消息大小上限，默认65535，如果发送超过此限制时会返回失败。
3 如果不考虑server进程挂掉等异常情况，未发现有丢消息或者重复投递的现象。如果client对接受的消息消费后没有反馈确认，server会认为该消息处理失败，会重复投递，直到成功。
4 同一个队列(tube)下，相同优先级的消息能保证顺序，优先级高的消息在优先级低的前面先被分发。
5 server/client使用tcp通信，服务端不支持异步。但有C语言的client使用非阻塞版本，使用回调函数进行异步IO操作。
6 客服端语言支持广泛，对php的支持也很好，客户端包括:c,c++,clojure,Common Lisp,Erlang,Go,java,Node.js,perl,php,python,ruby,c#。协议简单，很容易自己实现一个。
7 未有消息人导出，迁移可以能通过持久化后，移动binlog文件来操作。
8 消息可以持久化（时间间隔可指定，最短到每次），消息多机无冗余，开启持久化后消息几乎不会丢失。测试时持久化间隔1s，不停的写消息，期间kill掉server，重启后未发现消息有丢失。
9 支持对消息消费状态确认，在一定时间无反馈会继续当作未处理消息。
10 支持消息的延时投递，消息无在多机上无冗余备份，存在单点故障。
11 消息全部在内存中，消息容量依赖内存大小。
12 采用的类似memcache协议格式的自定义协议。
13 消息支持4种状态，特性较多，消费后的消息可以进行重复消费，延时消费，删除等操作。
14 部署容易，使用简单。
15 无故障处理切换机制。
16 水平扩展支持不是很好，采用类似memcache集群方式扩展，完全由client控制，某台server挂掉时也未能将tube rehash到另一台上的机制，不能动态增加或者减少服务器。
17 管理监控工具不是太完善，有类似memcache的统计状态查看命令（比memcache功能要差点），但比gearman命令要多一点。
18 服务用C开发(1.6版本是7.6k行）。
19 开发比较活跃(2012.5.9发的1.6版)，用户量一般。
20 不支持批量处理job，只能单个消息的push/pop。

性能等测试:
client和server在同一台机器，client使用Pheanstalk。
4核  Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
结果:
开启持久化(间隔1s -f 1000）
写10W个1k的数据15s
取这10W个的时间25s

无持久化:
写10W个1k的数据11.9s
取这10Wjob的时间21.8s


内存使用情况:
118141条一K的消息约占138M内存
615125条2字节消息约占120M内存

Gearman

 1 不支持pub/sub

2 单个job内容无大小限制。

3 不开启持久化时，进程挂掉后未job会立即丢失。开启持久化后能保证任务的可靠性（实测当服务器高速处理任务时突然挂掉，没发现有丢失任务的情况），当然如果外部存储问题就不能保证了。job无重复分发情况，

4 job是有顺序的，支持三个优先级。

5 job是同步发送给server，有异步或者同步的任务(类似RPC)。

6 对php支持很好，client有c,php,python,java,perl,c#

7 可以通过消息持久化存储的策略进行消息的迁移。

8 消息支持外部持久化，比如mysql,memcached等扩展。

9 支持对job是否成功的反馈确认，如果worker在执行job时崩溃或者退出，该job会再被分发（失败次数可以通过-j参数设定)。但如果使用job->sendFail()通知失败，则该job不会redo。

10  不支持延时任务（协议中本来有这个功能，但将会废弃)

11 消息容量受限于内存大小

12 server client交互是自定义的二进进制协议。

13 部署和使用起来比较简单，但相关管理界面不完善。

14 有故障切换机制，当配有多台server时，一台挂掉即会启用备份的server。但实际测试中该功能有一些问题，当server备份时，如果其中一台server挂掉后重启，那么client端可能会coredump。

15 目前服务器只作备份，当多个服务端同时使用时，client只会将所有任务发送到其中一台，无法在多个服务器均衡存储任务。可以动态增加减少服务器。

16 服务端为C语言， 代码约为7.5K

17 开发非常活跃，使用也非常广泛，像LiveJournal, Yahoo!, and Digg等公司使用。

20 不支持job的批量操作。

性能方面测试:
 配置:4核CPU  Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz   4G内存
client和server在同一台机器，使用持久化时，mysql也在同一台机器。

未持久化:
依次写入10W 512B的任务client的时间分别是
realtime   0m10.980s           0m14.888s              0m19.575s        0m24.072s
worker将这4oW任务按每次1oW分别取出的时间是:
realtime    0m21.717s         0m17.006s              0m13.300s        0m9.522s

持久化:
如果使用drizzle带上持久化写入mysql时，对应每次取10W的时间分别则是

real    0m30.873s         0m36.558s        0m41.199s     0m46.586s
worker读出这40W，第次10W的时间依次是:
real    0m48.448s          0m42.544s      0m37.864s      0m33.210s

1 当总的job数量为N时，服务器处理增加或者移出单个job的时间复杂度为O(N)。
2 实际测试时，如果push20W的job，通过一个client处理的时间与通过两个分别处理10W的时间差别不太大。持久化时这两个时间对比是66s:54s。未持久化的时间对比是:24s:21s

Kafka

 1. 有pub/sub功能，同步和异步都支持，producer.type项设置

2. 单条消息的上限用max.message.size项设置

3. 消息可能有丢失，在consumer宕机后消息可能有重复投递

4. 同一个partition内保证消息顺序，多个partition不保证

5. 支持异步发送消息，可配置producer使得在一定时间后发送消息，或是消息累积到一定量后再发送

6. 支持Scala、Java、C++、C#、Go、PHP、Python、Ruby，PHP需要5.3.3版本以上

7. PHP版本的client功能还不够丰富

8. 支持持久化，消息存储在磁盘上，复杂度为O(1)

9. 没有消费反馈，哪些消息已消费由consumer维护(通过记录一个offset值)，consumer也可以回滚到以前的位置，重新读取之前读取过的消息

10. 异步方式可支持消息的延时投递，queue.time项设置

11. 单个队列能够承受的消息容量的极限由queue.size项设置

12. 没有固定的协议

13. 消息的状态由客户端维护，服务端不参与，服务端会在消息保存一定时间(默认为7天)后将其删除

14. 每个consumer进程属于一个consumer group，一个message只被发给同一个consumer group中的一个consumer进程，因此可以支持queue和topic两种语义

15. producer发送消息后，broker不会发送ACK给producer

16. consumer与broker间有负载均衡

17. 在linux系统上使用sendfile系统调用，通过zero-copy技术达到很高的效率

18. 部署难度一般，配置管理还算方便

19. 最新版支持副本机制，解决了单点故障问题

20. 最新版支持镜像功能，可支持消息迁移，但还不太成熟，限制较多，如只能使用默认的patitioner等

21. 水平扩展方便，对业务无影响，Zookeeper管理consumer和broker的加入和退出

22. 也可以不依赖Zookeeper，那么事先需要在配置文件中指定机器信息，集群是静态的，不能变动

23. 消息支持压缩，节省网络开销，目前只支持gzip格式

24. 有安全机制和监控机制

25. 数据可批量导入hadoop，做离线数据分析

26. 设计指导思想是注重吞吐率更胜于注重功能特性

27. 未来会支持流式处理

28. Scala语言实现，代码行数不到6K，语言不熟悉但代码量不大

29. 开发较活跃，用户量较多，目前还在增长中

官网http://incubator.apache.org/kafka/