|
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-02-04
推荐一个参考， 关于Wotif如何从Active MQ 3 移植到Open MQ 4.0，以及移植后的效果:
http://blogs.sun.com/stories/entry/wotif_com_a_strong_openmq |
| 返回顶楼 | |
|
发表时间：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已经说过了。 |
| 返回顶楼 | |
|
发表时间：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怎样保证其稳定性？ |
| 返回顶楼 | |
|
发表时间：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线程长时间占用可能造成的服务拒绝。 |
| 返回顶楼 | |
|
发表时间：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万笔交易，对于一个系统来说这样巨大的请求量，真的很可怕，能否简单介绍一下这个系统的架构吗？ |
| 返回顶楼 | |
|
发表时间：2009-02-05
jboss MQ 现在已经不叫MQ了，叫jboss messaging，message1.4 or 2.0版本完全重构，如果在linux 或unix话，可以用JNI调用AIO，性能会更高。它们的官方报告上说是在同类开源产品中性能是最好的。并且messaging可以独立运行，不依赖于jboss。我看了一下他的源码，也非常容易看懂，并且代码量不大，建议你用messaging.如果性能上还有瓶颈，可以手工更改源码。
|
| 返回顶楼 | |
|
发表时间：2009-02-05
dyw8021 写道 jboss MQ 现在已经不叫MQ了，叫jboss messaging，message1.4 or 2.0版本完全重构，如果在linux 或unix话，可以用JNI调用AIO，性能会更高。它们的官方报告上说是在同类开源产品中性能是最好的。并且messaging可以独立运行，不依赖于jboss。我看了一下他的源码，也非常容易看懂，并且代码量不大，建议你用messaging.如果性能上还有瓶颈，可以手工更改源码。
兄弟的这个建议有建设性 
|
| 返回顶楼 | |
|
发表时间：2009-02-05
我用过jboss4.2的mq 作为 页面pv记录log，跟mdb配合数据入库。自己写的代码不出错的话，可以2年不重启jboss。
说一下使用经验： 1：不要使用额外数据库持久 jms消息，就使用默认的内存数据库就好。多了个数据库就多了个可能出错的口子，而且文档了的其他数据库的sql不完全正确。 2：如消费端出问题，导致消息积压过多，10w条以上，千万记得另写消费端把消息都消费了（可以简单下拉出来，等好了发回去），否则可能导致jboss不能重启，或者重启时间超长（超过1小时）。 另根据1.5年前的测试印象，jboss messaging也是个好东西。 |
| 返回顶楼 | |
|
发表时间：2009-04-26
yanlv1983 写道 ActiveMQ
我们公司以前用的是activemq，性能挺不错的 每秒钟并发量也超过1W了 不是吧activemq的并发量能超过1w？ibm的mq都没这个数字吧 |
| 返回顶楼 | |
|
发表时间：2009-04-26
aaa_star 写道 用过 activeMQ， 感觉还不错
有没有进行过性能测试呢？我很关系这样的数据 因为公司对这个比较感兴趣 |
| 返回顶楼 | |
