|
精华帖 (7) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-16
我们公司在实际开发时，就是使用ActiveMQ，但是发现在加载的时候有点慢，可能是我们没有配置好吧
|
| 返回顶楼 | |
|
发表时间：2009-01-16
linliangyi2007 写道 xokao 写道 目前activemq 支持均衡负载，包括定制比率和自动模式
如果你用nio发送模式，单台足够，可以使用M/S集群 但异步允许(1/10000)几率数据丢失 。 如果使用bio有点勉强，可以用一台作为前端分配器。其他的作为负载服务器。 但这里没有在实际使用过，需要验证，主要是对于前端的均衡负载服务器的单点处理问题。 难道需要在前段作为分配器的MQ做MS集群? 以上都缺乏足够经验来验证。。 我得方案是一个jboss带一个jms，然后是jboss的集群，当然，jms彼此间需要交叉发送备份信息，可以采用自己设计的，模仿raid的分发算法。 幻想一下，弄他8台服务器，交叉备份，哇卡卡卡，爽啊！！所以呢，jms选型很重要，不要等系统都设计完了，发现jms服务存在缺陷，那就郁闷了 方法不错，确实不需要局限与单纯的MQ 既然你选择jboss作为容器，可以试试jbossmessing , 以后如果有升级兼容性问题的处理上应该比较少。 请问下： 对于集群理解还不深，但对于交叉备份。 如果定时备份，必然降低数据可靠性。 可是如果采用及时增量复制备份，那么当压力大的情况下复制操作将会暂用大部分的操作。 楼主考虑过SNA没 |
| 返回顶楼 | |
|
发表时间：2009-01-16
最后修改：2009-01-18
现在mq们的集群方案，主推都是用DataBase 或 SAN来存储消息，8台MQ互相复制的做法不大现实。
另外，OpenMQ这个开源新贵Sun同志的产品也可以考虑下哦。 |
| 返回顶楼 | |
|
发表时间：2009-01-16
楼上， 本人以亲身体验， 并且以受害人的身份向你哭诉， 千万别用SUN的MQ。 痛苦， 实在是痛苦， 苦不堪言！！！ 这也是目前我这么关心MQ产品的原因。
自从用了sun mq, 出去旅游一定要带上本本， 带上上网卡，脚踏祖国名山大川， 眼盯黑压压终端屏幕。 |
| 返回顶楼 | |
|
发表时间：2009-01-16
最后修改：2009-01-16
江南白衣 写道 现在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服务器的点评啦，谢谢！！ |
| 返回顶楼 | |
|
发表时间：2009-01-16
linliangyi2007 写道 fjlyxx 写道 最近，开始引入jms来为公司整体应用集成进行技术预演
对于使用MQ去解决这个问题,我个人保留意见. 有这么几个问题第一无法进行协调工作,第二无法保证时性高效性,扩展不行.第三,不能体现整体应用的集成. 个人建议是使用 请求的模式, 应用间通过向需要的服务发出请求来实现不同系统间的集成.当然你需要开发一堆的适配器. 这个我部分认同，jms不是万能的。 但目前，我们需要一个jms，倒不一定是为了解决soa的调用，而是为了解决高并发情况下的任务队列处理。所以，回到正题，哪个jms实现更好呢？ActiveMQ、jBossMQ or others?? 解决高并发情况下的任务队列处理 我不知道你的任务是什么,但是我提一个问题.比如A向MQ发发送一个消息 很久都没有回复 那么你是否会继续向MQ发送这个消息呢?如果这样 你是否有足够的机制保障队列里面的消息不重复? 如果重复是否加重了服务的负载. 如果不重复那么这个消息是否又有可能发生死锁? 这是用第三方MQ会给你带来的烦恼. |
| 返回顶楼 | |
|
发表时间：2009-01-17
最后修改：2009-01-17
linliangyi2007 写道 楼上两位提醒的是。应该是我没有说清楚，我说的模仿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，来存储消息队列。 这个方案看起来很晕人，这个结构要完成的是什么样的工作，搞这么复杂 linliangyi2007 写道 目前的关键是，先选取一个高可靠，稳定且已扩展的jmx服务端，我们再根据它的一些特点来设计我们的整体服务架构。 还请兄弟们多给一些jmx服务器的点评啦，谢谢！！ jms?jmx? 关于jms选型的建议是：不要用jms 可考虑其他集成方案 |
| 返回顶楼 | |
|
发表时间：2009-01-17
linliangyi2007 写道 最近，开始引入jms来为公司整体应用集成进行技术预演。
从目前流行的开源jms框架中，看中了ActiveMQ和jBossMQ两款。由于还在选型阶段，所以谈不上对这两款jms有啥深入认识，之所以选他们有以下方面考虑。 1.并发性能。公司后期的业务需求接近4000并发/S； 2.稳定性。7×24的可靠，最少也要7×20 3.支持集群。需要集群技术提供负载均衡，横向扩展以及多机备份（防止单点故障）。 从网络上了解的资料，ActiveMQ的性能似乎更好一下，而且不依赖于特定的应用服务器，这个是它吸引我的地方； 选择jBossMQ的理由是，公司的主要应用都是跑在jBOSS上，这样集成起来，特别是后期的集群配置应该会省不少麻烦，而且jBossMQ的性能也很出色（虽然不如AMQ）。缺点是绑死在jBoss上。 希望用过这两jms服务的兄弟都给点经验和看法 
这个...坦率说，2个都不太行（前面有个哥们说的Jboss mq就像个demo产品，以前某个产品中用过，真的很头痛）。Active MQ，我现在的经理曾经试过，也不咋的。这2个基本都属于你需要常常去关心的东西，不属于用上后就放心的产品。 如果你公司穷，就别幻想用MQ，没得给自己添堵，否则IBMMQ，Weblogic（现在是Oracle了）或者EMS都可以。 |
| 返回顶楼 | |
|
发表时间：2009-01-17
4000/s 这个性能在IBM MQ也是个不错的数字，至少，发送一般很难到这个数字，接收还不错
至于MQ，我觉得Active比较好些，JBOSS绑的太紧，而且它底层用的MDB，这个是底层并发的，如果对数据的顺序有要求，请慎用 |
| 返回顶楼 | |
|
发表时间：2009-01-17
也在考虑mq的选型，倾向于ActiveMQ
|
| 返回顶楼 | |
