ActiveMQ VS jBossMQ的选型讨论，给点建议！
最近，开始引入jms来为公司整体应用集成进行技术预演。

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

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

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

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

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

4000并发也不是拍脑袋而来的，我们不得不认真的面对这个挑战。在此之前，我本人是没有接触过想这样同时需要高并发且高可靠的需求（做过单PC机800/s的，不过没有这么高的可靠性要求），这个让我自己都很捏把汗！！！
4000并发也不是拍脑袋而来的，我们不得不认真的面对这个挑战。在此之前，我本人是没有接触过想这样同时需要高并发且高可靠的需求（做过单PC机800/s的，不过没有这么高的可靠性要求），这个让我自己都很捏把汗！！！


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

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

如果只能两者中选，建议用active mq，原因上面的DX已经说过了。 4000并发也不是拍脑袋而来的，我们不得不认真的面对这个挑战。在此之前，我本人是没有接触过想这样同时需要高并发且高可靠的需求（做过单PC机800/s的，不过没有这么高的可靠性要求），这个让我自己都很捏把汗！！！


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

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

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

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


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万笔交易，对于一个系统来说这样巨大的请求量，真的很可怕，能否简单介绍一下这个系统的架构吗？
67 楼 byk 2009-02-05 我用过jboss4.2的mq 作为 页面pv记录log，跟mdb配合数据入库。自己写的代码不出错的话，可以2年不重启jboss。
说一下使用经验：
1：不要使用额外数据库持久 jms消息，就使用默认的内存数据库就好。多了个数据库就多了个可能出错的口子，而且文档了的其他数据库的sql不完全正确。
2：如消费端出问题，导致消息积压过多，10w条以上，千万记得另写消费端把消息都消费了（可以简单下拉出来，等好了发回去），否则可能导致jboss不能重启，或者重启时间超长（超过1小时）。
另根据1.5年前的测试印象，jboss messaging也是个好东西。 68 楼 portrait 2009-04-26 yanlv1983 写道ActiveMQ

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


不是吧activemq的并发量能超过1w？ibm的mq都没这个数字吧 69 楼 portrait 2009-04-26 aaa_star 写道用过 activeMQ， 感觉还不错
有没有进行过性能测试呢？我很关系这样的数据 因为公司对这个比较感兴趣