- 浏览: 1012634 次
- 性别:
- 来自: 福州
最新评论
-
guanxin2012:
大神,您好。非常感谢您贡献了IKExpression。我们现在 ...
分享开源表达式解析器IK-Expression2.0 -
qqgigas:
LZ,public boolean createUser(LD ...
Sun Directory Server/LDAP学习笔记(二)——API说明及代码样例 -
gao_shengxian:
Hibernate: update T_GX_TEST set ...
优雅Java编程 之 使用Hibernate存储Oracle Spatial对象 -
a78113534:
感谢大神,在安卓里面调用成功了。
发布IK Expression开源表达式解析器 V2.1.0 -
majiedota:
加油
来自开源支持者的第一笔捐赠
最近,开始引入jms来为公司整体应用集成进行技术预演。
从目前流行的开源jms框架中,看中了ActiveMQ和jBossMQ两款。由于还在选型阶段,所以谈不上对这两款jms有啥深入认识,之所以选他们有以下方面考虑。
1.并发性能。公司后期的业务需求接近4000并发/S;
2.稳定性。7×24的可靠,最少也要7×20
3.支持集群。需要集群技术提供负载均衡,横向扩展以及多机备份(防止单点故障)。
从网络上了解的资料,ActiveMQ的性能似乎更好一下,而且不依赖于特定的应用服务器,这个是它吸引我的地方;
选择jBossMQ的理由是,公司的主要应用都是跑在jBOSS上,这样集成起来,特别是后期的集群配置应该会省不少麻烦,而且jBossMQ的性能也很出色(虽然不如AMQ)。缺点是绑死在jBoss上。
希望用过这两jms服务的兄弟都给点经验和看法
有没有进行过性能测试呢?我很关系这样的数据 因为公司对这个比较感兴趣
不是吧activemq的并发量能超过1w?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万笔交易,对于一个系统来说这样巨大的请求量,真的很可怕,能否简单介绍一下这个系统的架构吗?
自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!
你还是没有说清楚4000并发/S是一个怎样的概念,如果只是WEB的并发访问,建议还是先优化再改架构!多一层却实是增加了一倍的灵活性,但如果你不熟悉MQ,反而会带来不必要的问题。
既然是选型,建议在列表中增加商用产品,这样不至于出了问题后自己没有台阶下。
如果只能两者中选,建议用active mq,原因上面的DX已经说过了。
4000笔/s的概念是,最高瞬时值时,同一秒内有4000次的业务请求到达,要求服务器能正常接收所有请求,不能出现阻塞,并在3-5秒的响应时间内完成相应的处理工作。这种高负载。在业务高峰时段,是一个持续的过程。4000笔每秒是按平均3000笔/s的业务量,乘以瞬时高峰的经验系数得到的.
使用jms,说白了就是希望借助其请求队列,来存储持续的高峰压力,缓解http线程长时间占用可能造成的服务拒绝。
确实,我也奇怪楼主的4000/s这数字是怎么来的?这样级别的需求不用商用的MQ怎样保证其稳定性?
自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!
你还是没有说清楚4000并发/S是一个怎样的概念,如果只是WEB的并发访问,建议还是先优化再改架构!多一层却实是增加了一倍的灵活性,但如果你不熟悉MQ,反而会带来不必要的问题。
既然是选型,建议在列表中增加商用产品,这样不至于出了问题后自己没有台阶下。
如果只能两者中选,建议用active mq,原因上面的DX已经说过了。
自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!
不必须 MQ 本身能独立运行。 Client端只需导入某些Jar. 从个人使用情况看来 WMQ 的单机收发消息速度是ActiveMQ 的1/5左右?
ActiveMQ4.2到ActiveMQ5.x无疑变化较大性能和稳定度都有所提升(单机) 。
作为集群类似功能,前面一位达人讲过: 使用一个MQ服务A,有后面若干MQ服务接收消息A的消息这样的路由方式我想来试试.当然有一定风险. 如交错拷贝数据性能无疑会有所下降。
不知大家对AMQP protocol 是否有使用,情况如何.
RabbitMQ呢那位达人使用过.现在版本无疑不是很成熟,看起来潜力蛮大.
能说的再详细点么,我们之前使用IBM MQ的时候非常稳定,且我们的消息量也非常大。而且,IBM MQ的各种功能队列分的很细,尤其是别名和模型队列非常实用
从目前流行的开源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了
不是吧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也是个好东西。
说一下使用经验:
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笔/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笔/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那样的天文数字,因为我们不是只做查询
我认为 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笔/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
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笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM MQ就非常好了,但能有如此大交易量业务的公司基本都是公司名中国打头的。
自豪的说,我们公司的确在自己的业内有较强的垄断地位 4000并发也不是拍脑袋而来的,我们不得不认真的面对这个挑战。在此之前,我本人是没有接触过想这样同时需要高并发且高可靠的需求(做过单PC机800/s的,不过没有这么高的可靠性要求),这个让我自己都很捏把汗!!!
58 楼
hsq972
2009-02-03
这个4000并发/s是一个怎样的概念,LZ要说清楚,否则就如楼上有人说的,或者根本就不需要MQ。
如果是4000笔/s的交易量。建议还是用商用的MQ吧!如上面说的IBM 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那样的天文数字,因为我们不是只做查询
我认为 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>
<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>
发表评论
-
来自开源支持者的第一笔捐赠
2013-01-09 21:15 57772013年1月9号,一个平凡而又不平常的日子! IK中文分词 ... -
发布 IK Analyzer 2012 FF 版本
2012-10-23 17:50 25073首先感谢大家对IK分词器的关注。 最近一段时间正式公司事务最 ... -
发布 IK Analyzer 2012 版本
2012-03-08 11:23 36163新版本改进: 支持分词歧义处理 支持数量词合并 词典支持中英 ... -
CSDN发生严重用户账号泄密事件
2011-12-21 19:21 2564之前有在CSDN注册过的兄弟们,注意了。。。 如果你的邮箱, ... -
一个隐形的java int溢出
2011-08-30 09:44 7555故事的背景: 笔者最近在做一个类SNS的项目,其中 ... -
雷军 :互联网创业的葵花宝典
2011-05-04 10:35 3593博主评: 这片博客很短 ... -
Luci-mint站内搜索实测
2011-04-02 16:18 4135关于Luci-mint 服务器硬 ... -
发布 IK Analyzer 3.2.8 for Lucene3.X
2011-03-04 17:49 14251IK Analyzer 3.2.8版本修订 ... -
TIPS - XML CDATA中的非法字符处理
2011-02-17 15:03 3301XML解析过程中,常遇见CDATA中存在非法字符,尤其在火星文 ... -
对Cassandra的初体验
2010-10-13 17:58 9132作为“云计算”时代的架构设计人员而言,不懂K-V库会被 ... -
Spring + iBatis 的多库横向切分简易解决思路
2010-10-11 13:43 93541.引言 笔者最近在做一个互联网的“类SNS”应用,应用 ... -
发布 IK Analyzer 3.2.5 稳定版 for Lucene3.0
2010-09-08 14:43 5822新版本IKAnnlyzer3.2.8已发布! 地址: http ... -
关于Lucene3.0.1 QueryParser的一个错误
2010-05-21 21:33 2128表达式1: 引用 id:"1231231" ... -
发布 IK Analyzer 3.2.3 稳定版 for Lucene3.0
2010-05-15 14:13 6715IK Analyzer 3.2.3版本修订 在3.2.0版 ... -
windows平台上的nginx使用
2010-01-28 17:13 3402转载自:http://nginx.org/en/docs/wi ... -
发布IKAnnlyzer3.2.0稳定版 for Lucene3.0
2009-12-07 09:27 9573最新3.2.5版本已经推出,http://linliangyi ... -
在Tomcat下以JNDI方式发布JbossCache
2009-12-04 10:57 3827前言: 看过JbossCache的开发手册,发现在Jb ... -
Spring AOP小例子
2009-11-16 10:35 3403PS: 要注明一下,这个是转载滴,之前漏了说鸟,汗死 这里给 ... -
ActiveMQ 5.X 与 Tomcat 集成一(JNDI部署)
2009-11-10 15:15 5648原文地址:http://activemq.apache.org ... -
发布IKAnalyzer中文分词器V3.1.6GA
2009-11-08 23:10 11854IKAnalyzer3.2.0稳定版已经发布,支持Lucene ...
相关推荐
在“简单的activemq点对点的同步消息模型”中,我们将探讨如何构建一个基本的、基于ActiveMQ的点对点消息传递系统,以及它的工作原理。 1. **点对点模型**:在JMS中,点对点模型(P2P)是一种消息传递模式,其中...
在实际项目中使用ActiveMQ-CPP Library时,开发者需要注意以下几点: 1. 配置环境:确保项目设置正确引用了ActiveMQ-CPP的库文件和头文件路径,以便编译器能找到必要的依赖。 2. 引入库:在源代码中,通过`#include...
TextMessage message = session.createTextMessage("Hello, ActiveMQ!"); producer.send(message); session.close(); connection.close(); } } ``` 对于接收者,同样需要创建连接工厂的实例,连接到服务器,...
ActiveMQ SSL配置教程!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ActiveMQ是一款非常流行的开源消息队列中间件,它实现了JMS(Java Message Service,Java消息服务)1.1规范,面向消息的中间件(Message Oriented Middleware,MOM)是指利用高效可靠的消息传递机制进行与平台无关的...
在这个"ActiveMQ的点对点与发布/订阅模式小demo"中,我们将深入理解这两种基本的消息传递模型,并了解如何在实践中运用ActiveMQ。 1. **点对点模式(Point-to-Point,P2P)**: 点对点模式是基于队列(Queue)的...
在`activeMQ_demo`这个压缩包中,可能包含了一些示例代码,用于演示如何使用ActiveMQ实现点对点和发布/订阅模式。这些示例可能包括了以下内容: 1. 生产者(Producer):创建和发送消息到队列或主题的代码,展示了...
在本文中,我们将深入探讨如何在Visual Studio 2017(简称VS2017)环境下成功配置和测试ActiveMQ-CPP,并分享2018年12月30日的测试经验。 首先,要开始使用ActiveMQ-CPP,我们需要确保我们的开发环境已经正确地设置...
ActiveMQ是中国最流行的开源消息中间件之一,由Apache软件基金会开发。它基于Java Message Service (JMS) 规范,提供了可靠的消息传递功能,适用于分布式系统中的应用间通信。本压缩包“activeMQ收发工具.rar”包含...
由于其速度快(通常比JBossMQ快10倍),并拥有Apache的持续发展支持,ActiveMQ与OpenJMS、JbossMQ等开源消息中间件相比具有明显优势。 部署ActiveMQ相对简单,主要步骤包括下载Distribution版本、安装以及启动...
消息队列:ActiveMQ:ActiveMQ消息类型:点对点与发布订阅.docx
标签"3.9.4,vs2010"进一步确认了我们正在讨论的是ActiveMQ C++客户端的特定版本以及它与Visual Studio 2010的兼容性。这表明开发者或者打包者已经解决了可能存在的兼容性问题,使得在VS2010中编译和运行ActiveMQ-CPP...
此测试涵盖了发布/订阅模型和点对点模型。 2.3 软硬件环境 硬件配置包括服务器的CPU、内存和磁盘性能,软件环境包括操作系统、JDK版本、ActiveMQ版本以及JMeter版本等。 2.4 网络环境 网络环境的稳定性和带宽限制...
本DEMO将深入探讨ActiveMQ中的两种主要通信模式:点对点(Point-to-Point,P2P)模型和发布/订阅(Publish/Subscribe,Pub/Sub)模型。 一、点对点(P2P)通信方式 1. 基本概念:在P2P模型中,消息从一个生产者...
### ActiveMQ-CPP 开发手册知识点详述 #### 一、引言 - **编写目的**:本手册旨在帮助开发者快速掌握 CMS (C++ Messaging Service) 的使用方法,提高 C++ 开发者在消息传递系统方面的开发效率,并作为 CMS 开发的...
### ActiveMQ 概述 Apache ActiveMQ 是一款非常流行的开源消息中间件,它支持 Java 消息服务 (JMS) 标准,并提供了多种高级功能,例如持久化、集群、故障转移等。ActiveMQ 能够帮助开发者实现解耦、可靠的消息传输...
1. **消息模型**:ActiveMQ支持多种消息模型,包括点对点(Queue)和发布/订阅(Topic)。在点对点模型中,消息由一个生产者发送到一个队列,然后由一个消费者接收并处理,每个消息只被消费一次。而在发布/订阅模型...
5. **消息队列和主题**:ActiveMQ提供两种消息模式:点对点(Queue)和发布/订阅(Topic)。点对点模式中,每个消息只有一个消费者,而发布/订阅模式下,一个消息可以被多个订阅者接收。 6. **消息过滤**:ActiveMQ...
### ActiveMQ高并发处理方案详解 #### 一、引言 在现代分布式系统中,消息队列作为异步通信的核心组件之一,对于提高系统的吞吐量、降低响应时间和实现服务解耦等方面起着至关重要的作用。Apache ActiveMQ作为一款...
在本文中,我们将深入探讨如何使用Spring框架与Apache ActiveMQ集成,实现点对点通信(Point-to-Point)和发布/订阅(Publish/Subscribe)模式的通信。ActiveMQ是流行的开源消息中间件,它允许应用程序之间异步传输...