ActiveMQ VS jBossMQ的选型讨论，给点建议！

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

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

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

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

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

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

评论

49 楼 fjlyxx 2009-01-19  

linliangyi2007 写道

楼上的兄弟，你没明白我的意思，我是想从应用层同时向两个jms发送消息，一个主送，一个备份，不存在你说的J0负责所有请求，否则又是一个单一故障点咯，这样的群集就没有意义了

其实这和你说的并不违背,我只是想把负载均衡的功能从应用中剥离出来,不要加重应用本身的逻辑.不好意思习惯了用适配去补救原有应用的不足.因为改现有稳定的应用毕竟是比较麻烦和高风险的事情.

48 楼 cats_tiger 2009-01-19  

<div class="quote_title">andyao 写道</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>明显误导人,</p>
<p>你这个个表中的JBossMQ和ActiveMQ要对掉一下.</p>
<p> </p>
<p> </p>
</div>
<p>抱歉，抱歉，写反了</p>

47 楼 cats_tiger 2009-01-19  

<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>

46 楼 linliangyi2007 2009-01-19  

楼上的兄弟，你没明白我的意思，我是想从应用层同时向两个jms发送消息，一个主送，一个备份，不存在你说的J0负责所有请求，否则又是一个单一故障点咯，这样的群集就没有意义了

45 楼 fjlyxx 2009-01-19  

linliangyi2007 写道

江南白衣 写道

现在mq们的集群方案，主推都是用DataBase 或 SNA来存储消息，8台MQ互相复制的做法不大现实。

另外，OpenMQ这个开源新贵Sun同志的产品也可以考虑下哦。

楼上两位提醒的是。应该是我没有说清楚，我说的模仿RAID的算法大体是这样的：
假设有8台的jBoss，J0 - J7；
当一个用户请求到达J0时，向J0的jms队列发送一条M0,J0收到后根据特定算法，它将发送一个备份消息到J3的jms中、，主--备消息可能有如下映射：
J0-->J3
J1-->J4
J2-->J5
J3-->J6
J4-->J7
J5-->J0
J6-->J1
J7-->J2
如果这时J3宕机，J6上的备份信息将继续处理，确保J3上的请求不会丢失。与此同时，J0的备份信息将发往J6，如此，按照一定算法循环，简单模拟RAID的存储备份规则。
同时每台JMS有自己的本地数据库，考虑采用简单一点的如MySQL，来存储消息队列。

在8台jBoss都正常的情况下，通过IP分配原则，分摊来自不同IP的请求。以这样的集群方式，应付高并发，且又要求高可靠的生产环境。哪怕一台服务器每秒只有500个请求的处理能力，8台也能轻松应付4000笔业务的峰值。

这个目前只是一个很粗很粗的设计思路，不要问我具体的技术细节哦，我也没去细想呢，呵呵！

目前的关键是，先选取一个高可靠，稳定且已扩展的jmx服务端，我们再根据它的一些特点来设计我们的整体服务架构。
还请兄弟们多给一些jmx服务器的点评啦，谢谢！！

这样行不?
J0是引导队列,它负责接收所有的请求.
J1--J7都从JO去取值,或者JO主动将队列值推给J1--J7 让J1-J7达到负载均衡.
对于匿机备份 还是需要在J0这段进行详细的任务日志记录,在没有很好监控的条件下匿机备份简直就是梦话.这点也是我排斥用第三方MQ的原因.现在用IBM MQ只能是客户端和服务端进行约定,看消息是否丢失或者异常,这个成本太高了.

44 楼 fjlyxx 2009-01-19  

对JbossMQ ActiveMQ 不太了解,IBM MQ一直在用,感觉马马虎虎.IBM MQ在有内外网的时候总是慢半拍,客户端死掉的时候再次连接总是摆工. 短连接长连接一起上还是不怎么稳定.需要写一大堆的适配器去迎合IBM的标准.

43 楼 linliangyi2007 2009-01-19  

哇，开始出现不同意见咯！！
理不辨不明，期待有大拿给权威答案

42 楼 andyao 2009-01-19  

<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>明显误导人,</p>
<p>你这个个表中的JBossMQ和ActiveMQ要对掉一下.</p>
<p> </p>
<p> </p>

41 楼 jnn 2009-01-19  

闲着也是闲着 写道

JBOSS MQ是以前的故事了，新的叫JBoss Messaging，整体稳定性和性能有大幅提高。如果你们有JBoss支持，建议用Jboss Messaging，毕竟出了问题也算有靠山...

ActiveMQ历史长，也相当成熟，特别是它有各种语言的客户端库，包括C/CPP等。如果你们的系统里涉及多种平台和语言，用JBoss Messaging就不爽了。不过ActiveMQ的商用支持在国内没怎么听说过。

传说JBoss Messaging可以用一种broker和ActiveMQ连起来，这样也算变相提供了多种语言的支持，俺没用过，稳定性难说。

对于大规模商用系统，厂商二线技术支持是必须考虑的事情，否则出了事情哭都没有地方哭...

哈，商业支持可以找Progress啊
目前AcitveMQ的绝大多数Committer都就职于Progress，负责维护 http://fusesource.com/

40 楼 jnn 2009-01-19  

<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>

39 楼 linliangyi2007 2009-01-18  

感谢，葱白，楼上各位，尤其是firebody大大和sdh5724大大为我提供了系统设计思路和性能数据的支持。

38 楼 闲着也是闲着 2009-01-18  

JBOSS MQ是以前的故事了，新的叫JBoss Messaging，整体稳定性和性能有大幅提高。如果你们有JBoss支持，建议用Jboss Messaging，毕竟出了问题也算有靠山...

ActiveMQ历史长，也相当成熟，特别是它有各种语言的客户端库，包括C/CPP等。如果你们的系统里涉及多种平台和语言，用JBoss Messaging就不爽了。不过ActiveMQ的商用支持在国内没怎么听说过。

传说JBoss Messaging可以用一种broker和ActiveMQ连起来，这样也算变相提供了多种语言的支持，俺没用过，稳定性难说。

对于大规模商用系统，厂商二线技术支持是必须考虑的事情，否则出了事情哭都没有地方哭...

37 楼 yanlv1983 2009-01-18  

ActiveMQ

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

36 楼 sdh5724 2009-01-18  

楼上所言甚是。 只要没有大规模的计算。 WEBSERVER的程序只要不是胡乱整的。 业务上处理基本不会有问题。 怕的就是乱整， 比如一次读成千上万的数据， 或者反复开启事务处理。  一般来说， 你的系统上不了100并发， 基本是乱写的成份大一点。 现在的硬件能力太强了， 强到了可以让程序员不关心内存使用， 强到可以不关心一个计算花费多少时间， 强大到可以在后期压力测试中发现问题， 解决问题。

如果仅仅是发送消息的处理， 每秒接收4000消息不是问题。 等等， 我发测试报告到BLOG。 可以参考下。


http://sdh5724.iteye.com/blog/318376

35 楼 firebody 2009-01-18  

linliangyi2007 写道

谢谢楼上各位大大。

对于高并发，如果不用消息队列的形式，如果能承受峰值的请求处理呢？
比较明确的一点是，如果发生4000/s的请求，如果直接调用业务逻辑执行，几乎是不可能。一次完成业务处理基本要大几十毫秒的。在我看来，一个是靠群集分担处理，另一个就只能靠队列来处理请求了，否则服务器关应付HTTP的线程等待，估计就要爆了。

压力测试需要自己设计和去做的。
光听别人说都没用。  可以很负责任的告诉你，每个业务处理几十毫秒，500个并发上来，HTTP服务器不会爆。不过，服务器的配置就是需要更仔细和谨慎了。

34 楼 firebody 2009-01-18  

linliangyi2007 写道

江南白衣 写道

现在mq们的集群方案，主推都是用DataBase 或 SNA来存储消息，8台MQ互相复制的做法不大现实。

另外，OpenMQ这个开源新贵Sun同志的产品也可以考虑下哦。

楼上两位提醒的是。应该是我没有说清楚，我说的模仿RAID的算法大体是这样的：
假设有8台的jBoss，J0 - J7；
当一个用户请求到达J0时，向J0的jms队列发送一条M0,J0收到后根据特定算法，它将发送一个备份消息到J3的jms中、，主--备消息可能有如下映射：
J0-->J3
J1-->J4
J2-->J5
J3-->J6
J4-->J7
J5-->J0
J6-->J1
J7-->J2
如果这时J3宕机，J6上的备份信息将继续处理，确保J3上的请求不会丢失。与此同时，J0的备份信息将发往J6，如此，按照一定算法循环，简单模拟RAID的存储备份规则。
同时每台JMS有自己的本地数据库，考虑采用简单一点的如MySQL，来存储消息队列。

在8台jBoss都正常的情况下，通过IP分配原则，分摊来自不同IP的请求。以这样的集群方式，应付高并发，且又要求高可靠的生产环境。哪怕一台服务器每秒只有500个请求的处理能力，8台也能轻松应付4000笔业务的峰值。

这个目前只是一个很粗很粗的设计思路，不要问我具体的技术细节哦，我也没去细想呢，呵呵！

目前的关键是，先选取一个高可靠，稳定且已扩展的jmx服务端，我们再根据它的一些特点来设计我们的整体服务架构。
还请兄弟们多给一些jmx服务器的点评啦，谢谢！！

4000/s的并发，是比较高，需要集群来做横向扩展的。
应用服务器的集群可以是 硬负载均衡器+应用服务器集群来达到。8台的话，每个应用服务器承载500/s的并发。

数据库集群我做企业应用主要就是用Oracle的RAC，Mysql的集群基本没有接触。

剩下的就是估计数据库服务器承载量的问题，估算前给一个具体的性能要求：
   每笔业务响应时间最长不超过10S。（10S的响应时间在峰值下，我认为还是合理的）

   按照你给出的估计，每笔业务处理的数据库交互假设需要50ms,我们来估算一下单台数据库服务器是否能够在性能需求下应付4000/s的并发访问。

  数据库最大连接数100.

  (4000/100)*(50ms) = 40*50ms = 2000ms.
  加多30%的冗余误差， 2000*130/100 = 2600ms .

也就是说： 3秒之内，数据库服务器就可以处理完4000笔并发。最长等待时间不超过3秒。


从这个角度来看，只要每笔业务处理的SQL性能优化很好，每笔SQL响应时间控制在100毫秒以内，数据库集群根本不需要，当然，数据库服务器的硬件配置要配置优越。

应用服务器的设计在开始的时候，考虑横向扩展的兼容，后面基本没啥大问题。

复杂的设计方案，就是采用你说的 MS消息队列来处理任务等待队列的问题了。
这样的方案，是可以支撑大并发的服务的，但是也就仅仅支撑而已，并没有给性能带来多大好处，更不好的还是引入了一个新的中间层技术，增加了设计复杂度。整体开发规模也要上去的。

所以，我的意见是，除非设计多个不同应用体系集成，如果是自身单一体系的设计，不要考虑MS。

当然，即使多个应用体系的集成，也不一定非要MS不可。 还有WS多种方案处理，MS最好的地方就在于队列缓存，消息分发。 这些在多异平台应用集成时，会派上大用场。

33 楼 sdh5724 2009-01-18  

wym0291 写道

sdh5724 写道

楼上， 本人以亲身体验， 并且以受害人的身份向你哭诉， 千万别用SUN的MQ。 痛苦， 实在是痛苦， 苦不堪言！！！ 这也是目前我这么关心MQ产品的原因。
自从用了sun mq, 出去旅游一定要带上本本， 带上上网卡，脚踏祖国名山大川， 眼盯黑压压终端屏幕。

.....能说详细点么，这个我非常关心。SUN的MQ在某些方面确实易用性不好，管理端的用词也容易让人迷惑，明明是将连接配置保存在一个文件里，却把一个本地文件路径当成jndi。

   简单点， 你发个1000W消息给SUN MQ， 看看他还能不能活过来， 消息堆积多了， 慢就慢吧， 那总得慢的能让我处理掉啊， 直接死了， 算个什么可靠性， 要直接删除存储文件才能起来， 如果是关键业务， 想象吧， 死人呐。 或者发几百万， 然后重新启动， 看他还能不能活过来。你能保证的消息的被完全处理， 就当我没有说过。
  最可笑的是， 有时候， 连接什么的都完全正常， 消息看上去发的很正常， 服务器却没有收到。当然这个机会很少， 我碰到过几次。还有很多BUG， 报告给SUN， 也得到了BUG确认， 修复动作特别迟缓。 半年也不给发布。 受不了。 最后决定撤出所有sun相关的软件， 一律不用。

32 楼 fjlyxx 2009-01-18  

解决高并发情况下的任务队列处理

我不知道你的任务是什么,但是我提一个问题.比如A向MQ发发送一个消息 很久都没有回复 那么你是否会继续向MQ发送这个消息呢?如果这样你是否有足够的机制保障队列里面的消息不重复? 如果重复是否加重了服务的负载. 如果不重复那么这个消息是否又有可能发生死锁? 这是用第三方MQ会给你带来的烦恼.

这个种问题是用MQ队列无法避免的,超时,重复.怎么解决

31 楼 linliangyi2007 2009-01-17  

谢谢楼上各位大大。

对于高并发，如果不用消息队列的形式，如果能承受峰值的请求处理呢？
比较明确的一点是，如果发生4000/s的请求，如果直接调用业务逻辑执行，几乎是不可能。一次完成业务处理基本要大几十毫秒的。在我看来，一个是靠群集分担处理，另一个就只能靠队列来处理请求了，否则服务器关应付HTTP的线程等待，估计就要爆了。

30 楼 wym0291 2009-01-17  

sdh5724 写道

楼上， 本人以亲身体验， 并且以受害人的身份向你哭诉， 千万别用SUN的MQ。 痛苦， 实在是痛苦， 苦不堪言！！！ 这也是目前我这么关心MQ产品的原因。
自从用了sun mq, 出去旅游一定要带上本本， 带上上网卡，脚踏祖国名山大川， 眼盯黑压压终端屏幕。

.....能说详细点么，这个我非常关心。SUN的MQ在某些方面确实易用性不好，管理端的用词也容易让人迷惑，明明是将连接配置保存在一个文件里，却把一个本地文件路径当成jndi。