|
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 作者 | 正文 | ||||||||||||||||||||||||
|
发表时间：2009-01-20
cats_tiger 写道
jnn 写道
cats_tiger 写道
不知道这位的哥们的星都怎么给的，据我所知 ActiveMQ的使用范围，文档，案例，以及社区活跃程度比JBossMQ要强很多。 天哪，我写反了！！！！！
哥么，你太强哩，葱白一下！！看来论坛上几乎一边倒啊～～～～ |
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-01-21
fjlyxx 写道 对JbossMQ ActiveMQ 不太了解,IBM MQ一直在用,感觉马马虎虎.IBM MQ在有内外网的时候总是慢半拍,客户端死掉的时候再次连接总是摆工. 短连接长连接一起上还是不怎么稳定.需要写一大堆的适配器去迎合IBM的标准.
能说的再详细点么，我们之前使用IBM MQ的时候非常稳定，且我们的消息量也非常大。而且，IBM MQ的各种功能队列分的很细，尤其是别名和模型队列非常实用 |
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：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那样的天文数字，因为我们不是只做查询 |
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-01
呵呵,说了这么多还不如买个商用的MQ呢,比如IBM的WMQ,感觉挺好用!
|
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-01
问，如果使用IBM的MQ是否意味着App Server要使用websphere？？
|
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-02
用过 activeMQ， 感觉还不错
|
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-02
本人使用了 bea的，感觉还不错，但是没有发现任何一家厂商提供 jms的群集服务。
|
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：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呢那位达人使用过.现在版本无疑不是很成熟，看起来潜力蛮大. |
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-03
这个4000并发/s是一个怎样的概念，LZ要说清楚，否则就如楼上有人说的，或者根本就不需要MQ。
如果是4000笔/s的交易量。建议还是用商用的MQ吧！如上面说的IBM MQ就非常好了，但能有如此大交易量业务的公司基本都是公司名中国打头的。 |
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
|
发表时间：2009-02-03
hsq972 写道 这个4000并发/s是一个怎样的概念，LZ要说清楚，否则就如楼上有人说的，或者根本就不需要MQ。
如果是4000笔/s的交易量。建议还是用商用的MQ吧！如上面说的IBM MQ就非常好了，但能有如此大交易量业务的公司基本都是公司名中国打头的。 自豪的说，我们公司的确在自己的业内有较强的垄断地位  4000并发也不是拍脑袋而来的，我们不得不认真的面对这个挑战。在此之前，我本人是没有接触过想这样同时需要高并发且高可靠的需求（做过单PC机800/s的，不过没有这么高的可靠性要求），这个让我自己都很捏把汗！！！
|
||||||||||||||||||||||||
| 返回顶楼 | |||||||||||||||||||||||||
