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. 有认证和授权等安全机制
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://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/
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. 开发较活跃，用户量较多，目前还在增长中
