欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

消息队列系统对比

架构&设计模式 water 4230℃ 0评论

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/

转载请注明:学时网 » 消息队列系统对比

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!