`
linliangyi2007
  • 浏览: 1003379 次
  • 性别: Icon_minigender_1
  • 来自: 福州
社区版块
存档分类
最新评论

ActiveMQ VS jBossMQ的选型讨论,给点建议!

阅读更多
最近,开始引入jms来为公司整体应用集成进行技术预演。

从目前流行的开源jms框架中,看中了ActiveMQ和jBossMQ两款。由于还在选型阶段,所以谈不上对这两款jms有啥深入认识,之所以选他们有以下方面考虑。

1.并发性能。公司后期的业务需求接近4000并发/S;
2.稳定性。7×24的可靠,最少也要7×20
3.支持集群。需要集群技术提供负载均衡,横向扩展以及多机备份(防止单点故障)。

从网络上了解的资料,ActiveMQ的性能似乎更好一下,而且不依赖于特定的应用服务器,这个是它吸引我的地方;

选择jBossMQ的理由是,公司的主要应用都是跑在jBOSS上,这样集成起来,特别是后期的集群配置应该会省不少麻烦,而且jBossMQ的性能也很出色(虽然不如AMQ)。缺点是绑死在jBoss上。

希望用过这两jms服务的兄弟都给点经验和看法

分享到:
评论
69 楼 portrait 2009-04-26  
aaa_star 写道
用过 activeMQ, 感觉还不错

有没有进行过性能测试呢?我很关系这样的数据 因为公司对这个比较感兴趣
68 楼 portrait 2009-04-26  
yanlv1983 写道
ActiveMQ

我们公司以前用的是activemq,性能挺不错的
每秒钟并发量也超过1W了


不是吧activemq的并发量能超过1w?ibm的mq都没这个数字吧
67 楼 byk 2009-02-05  
我用过jboss4.2的mq 作为 页面pv记录log,跟mdb配合数据入库。自己写的代码不出错的话,可以2年不重启jboss。
说一下使用经验:
1:不要使用额外数据库持久 jms消息,就使用默认的内存数据库就好。多了个数据库就多了个可能出错的口子,而且文档了的其他数据库的sql不完全正确。
2:如消费端出问题,导致消息积压过多,10w条以上,千万记得另写消费端把消息都消费了(可以简单下拉出来,等好了发回去),否则可能导致jboss不能重启,或者重启时间超长(超过1小时)。
另根据1.5年前的测试印象,jboss messaging也是个好东西。
66 楼 linliangyi2007 2009-02-05  
dyw8021 写道
jboss MQ 现在已经不叫MQ了,叫jboss messaging,message1.4 or 2.0版本完全重构,如果在linux 或unix话,可以用JNI调用AIO,性能会更高。它们的官方报告上说是在同类开源产品中性能是最好的。并且messaging可以独立运行,不依赖于jboss。我看了一下他的源码,也非常容易看懂,并且代码量不大,建议你用messaging.如果性能上还有瓶颈,可以手工更改源码。


兄弟的这个建议有建设性
65 楼 dyw8021 2009-02-05  
jboss MQ 现在已经不叫MQ了,叫jboss messaging,message1.4 or 2.0版本完全重构,如果在linux 或unix话,可以用JNI调用AIO,性能会更高。它们的官方报告上说是在同类开源产品中性能是最好的。并且messaging可以独立运行,不依赖于jboss。我看了一下他的源码,也非常容易看懂,并且代码量不大,建议你用messaging.如果性能上还有瓶颈,可以手工更改源码。
64 楼 hsq972 2009-02-05  
linliangyi2007 写道
hsq972 写道
linliangyi2007 写道
hsq972 写道
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。

如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。


自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!


你还是没有说清楚4000并发/S是一个怎样的概念,如果只是WEB的并发访问,建议还是先优化再改架构!多一层却实是增加了一倍的灵活性,但如果你不熟悉MQ,反而会带来不必要的问题。

既然是选型,建议在列表中增加商用产品,这样不至于出了问题后自己没有台阶下。

如果只能两者中选,建议用active mq,原因上面的DX已经说过了。


4000笔/s的概念是,最高瞬时值时,同一秒内有4000次的业务请求到达,要求服务器能正常接收所有请求,不能出现阻塞,并在3-5秒的响应时间内完成相应的处理工作。这种高负载。在业务高峰时段,是一个持续的过程。4000笔每秒是按平均3000笔/s的业务量,乘以瞬时高峰的经验系数得到的.
使用jms,说白了就是希望借助其请求队列,来存储持续的高峰压力,缓解http线程长时间占用可能造成的服务拒绝。




“并在3-5秒的响应时间内完成相应的处理工作”,按一笔交易最大时长5秒算,也就是每秒处理800笔交易,这也是一个巨大的数字了,个人建议上商用MQ吧!

同一秒内有4000次的业务请求到达,如果按业务高峰时段持续过程为30分钟算,也是720万个请求,144万笔交易,对于一个系统来说这样巨大的请求量,真的很可怕,能否简单介绍一下这个系统的架构吗?
63 楼 linliangyi2007 2009-02-04  
hsq972 写道
linliangyi2007 写道
hsq972 写道
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。

如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。


自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!


你还是没有说清楚4000并发/S是一个怎样的概念,如果只是WEB的并发访问,建议还是先优化再改架构!多一层却实是增加了一倍的灵活性,但如果你不熟悉MQ,反而会带来不必要的问题。

既然是选型,建议在列表中增加商用产品,这样不至于出了问题后自己没有台阶下。

如果只能两者中选,建议用active mq,原因上面的DX已经说过了。


4000笔/s的概念是,最高瞬时值时,同一秒内有4000次的业务请求到达,要求服务器能正常接收所有请求,不能出现阻塞,并在3-5秒的响应时间内完成相应的处理工作。这种高负载。在业务高峰时段,是一个持续的过程。4000笔每秒是按平均3000笔/s的业务量,乘以瞬时高峰的经验系数得到的.
使用jms,说白了就是希望借助其请求队列,来存储持续的高峰压力,缓解http线程长时间占用可能造成的服务拒绝。


62 楼 hsq972 2009-02-04  
xiao007hua 写道
个人认为IBM MQ是一个非常稳定的产品,并且故障率几乎为零,集群情况下测试结果非常好
我认为 firebody 说的非常正确,但是也有一些部分值得商榷

   1)我不认为用了jms还需要http服务器,首先应用可以直接处理jms请求,响应jms报文
   2) 数据库服务器是一个非常大的瓶颈,并发量的提高与数据库的每笔处理速度和数据库可提供的有效的连接数有绝对关系,跟jms本身无关,因为jms处理方式本身支持足够的并发量,mq本身也支持足够的并发量,瓶颈在于数据库
   3) 我个人认为1000笔/s是处理的上限,根本不可能达到4000/s的处理能力,单笔业务的平均处理时间在100ms以内已经很不错了,如果是那种直接查询结果的特别简单交易会是50ms,其余应该都在100ms以内已经是非常理想的了
   4)项目里面是使用的IBM MQ,非常稳定,另外mq做好了集群以后
   5) 应该关心每秒可以处理多少笔,而不是每秒多少请求,因为每秒可以处理的笔数才是应用程序压力的体现,另外java程序的调优还和垃圾收集,日志处理,程序本身的并发性有关系
   总之,用jms可以优化现有的程序,并且jms不会成为瓶颈,但是也不会出现4000/s那样的天文数字,因为我们不是只做查询


确实,我也奇怪楼主的4000/s这数字是怎么来的?这样级别的需求不用商用的MQ怎样保证其稳定性?
61 楼 hsq972 2009-02-04  
linliangyi2007 写道
hsq972 写道
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。

如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。


自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!


你还是没有说清楚4000并发/S是一个怎样的概念,如果只是WEB的并发访问,建议还是先优化再改架构!多一层却实是增加了一倍的灵活性,但如果你不熟悉MQ,反而会带来不必要的问题。

既然是选型,建议在列表中增加商用产品,这样不至于出了问题后自己没有台阶下。

如果只能两者中选,建议用active mq,原因上面的DX已经说过了。
60 楼 家常咖啡 2009-02-04  
推荐一个参考, 关于Wotif如何从Active MQ 3 移植到Open MQ 4.0,以及移植后的效果:
http://blogs.sun.com/stories/entry/wotif_com_a_strong_openmq
59 楼 linliangyi2007 2009-02-03  
hsq972 写道
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。

如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。


自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!
58 楼 hsq972 2009-02-03  
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。

如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。
57 楼 ljxml 2009-02-02  
linliangyi2007 写道
问,如果使用IBM的MQ是否意味着App Server要使用websphere??


不必须 MQ 本身能独立运行。 Client端只需导入某些Jar. 从个人使用情况看来 WMQ 的单机收发消息速度是ActiveMQ 的1/5左右?

ActiveMQ4.2到ActiveMQ5.x无疑变化较大性能和稳定度都有所提升(单机) 。
作为集群类似功能,前面一位达人讲过: 使用一个MQ服务A,有后面若干MQ服务接收消息A的消息这样的路由方式我想来试试.当然有一定风险. 如交错拷贝数据性能无疑会有所下降。

不知大家对AMQP protocol 是否有使用,情况如何.

RabbitMQ呢那位达人使用过.现在版本无疑不是很成熟,看起来潜力蛮大.
56 楼 davexin 2009-02-02  
本人使用了 bea的,感觉还不错,但是没有发现任何一家厂商提供 jms的群集服务。
55 楼 aaa_star 2009-02-02  
用过 activeMQ, 感觉还不错
54 楼 linliangyi2007 2009-02-01  
问,如果使用IBM的MQ是否意味着App Server要使用websphere??
53 楼 chenzh1314 2009-02-01  
呵呵,说了这么多还不如买个商用的MQ呢,比如IBM的WMQ,感觉挺好用!
52 楼 xiao007hua 2009-02-01  
个人认为IBM MQ是一个非常稳定的产品,并且故障率几乎为零,集群情况下测试结果非常好
我认为 firebody 说的非常正确,但是也有一些部分值得商榷

   1)我不认为用了jms还需要http服务器,首先应用可以直接处理jms请求,响应jms报文
   2) 数据库服务器是一个非常大的瓶颈,并发量的提高与数据库的每笔处理速度和数据库可提供的有效的连接数有绝对关系,跟jms本身无关,因为jms处理方式本身支持足够的并发量,mq本身也支持足够的并发量,瓶颈在于数据库
   3) 我个人认为1000笔/s是处理的上限,根本不可能达到4000/s的处理能力,单笔业务的平均处理时间在100ms以内已经很不错了,如果是那种直接查询结果的特别简单交易会是50ms,其余应该都在100ms以内已经是非常理想的了
   4)项目里面是使用的IBM MQ,非常稳定,另外mq做好了集群以后
   5) 应该关心每秒可以处理多少笔,而不是每秒多少请求,因为每秒可以处理的笔数才是应用程序压力的体现,另外java程序的调优还和垃圾收集,日志处理,程序本身的并发性有关系
   总之,用jms可以优化现有的程序,并且jms不会成为瓶颈,但是也不会出现4000/s那样的天文数字,因为我们不是只做查询
51 楼 wym0291 2009-01-21  
fjlyxx 写道
对JbossMQ ActiveMQ 不太了解,IBM MQ一直在用,感觉马马虎虎.IBM MQ在有内外网的时候总是慢半拍,客户端死掉的时候再次连接总是摆工. 短连接长连接一起上还是不怎么稳定.需要写一大堆的适配器去迎合IBM的标准.



能说的再详细点么,我们之前使用IBM MQ的时候非常稳定,且我们的消息量也非常大。而且,IBM MQ的各种功能队列分的很细,尤其是别名和模型队列非常实用
50 楼 linliangyi2007 2009-01-20  
<div class="quote_title">cats_tiger 写道</div>
<div class="quote_div">
<div class="quote_title">jnn 写道</div>
<div class="quote_div">
<div class="quote_title">cats_tiger 写道</div>
<div class="quote_div">
<p> </p>
<table border="0">
<tbody>
<tr>
<td></td>
<td>成熟 </td>
<td>性能 </td>
<td>功能 </td>
<td>文档 </td>
<td>网络资源 </td>
<td>案例 </td>
<td>社区</td>
</tr>
<tr>
<td>JbossMQ</td>
<td>★</td>
<td>★</td>
<td>★</td>
<td>★</td>
<td>★</td>
<td>★</td>
<td>★</td>
</tr>
<tr>
<td>ActiveMQ</td>
<td></td>
<td></td>
<td>★</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<p> </p>
<p> </p>
</div>
<p>不知道这位的哥们的星都怎么给的,据我所知 ActiveMQ的使用范围,文档,案例,以及社区活跃程度比JBossMQ要强很多。</p>
</div>
<p>天哪,我写反了!!!!!</p>
</div>
<p> </p>
<p>哥么,你太强哩,葱白一下!!看来论坛上几乎一边倒啊~~~~</p>

相关推荐

Global site tag (gtag.js) - Google Analytics