600分！JMS选型，ActiveMQ还是JORAM？

有这方面经验的高手出来说说啊！另一给分点：
http://community.csdn.net/Expert/topic/4820/4820983.xml?temp=.2582819

解决方案 »

  1.   


    写错了
    另一给分点：
    http://community.csdn.net/Expert/topic/4820/4820983.xml?temp=.3051111
      

  2.   

    我觉得 sun 的message queue 是相当不错的。 
    cluster软集群技术， 如果你采用硬件方面的 HA或者 load balance 也可以还有一点，你上面提到的 在网络连接出错以后无法得到错误的通知。 其实这个是你还不够了解jms connection比如你弄了2个 jms server ，他们构建成一个cluster，如果一台挂了（stop server，或者网洛断了），那么client端自然会将连接转移到另外一台。当然这个是sun messageuque的client帮你做的。与jms connection 连接的时候，最好能够采用JCA的技术，帮你管理连接。
      

  3.   

    csrcom(泥鳅)大侠：你可要多指导指导，我现在正在选型阶段，我会做如下的测试：1：高可靠性、高稳定性
       从美国的服务器发送100万条消息到中国的服务器，要求不能丢消息，而且最好支持SSL；2：消息消费者集群
       这个好办，增加一个消费者到同一个queue就可以了3：broker集群
       因为可能这个queue也成为瓶颈，所以也要集群。（我不知道，假如有足够的消费者处理消息，这个queue会不会成为瓶颈，按理来说，应该不会）我不知道broker集群的意义是HA，还是真的也需要负载均衡？
    请高手多指点！
      

  4.   

    请有activemq方面的开发经验的高手指导指导,让我们少走弯路,让我们分享一手的实践经验.
      

  5.   

    看你的需求要求还挺高,为什么不用IBM的MQ呢?好像也不贵
      

  6.   

    你不能依靠 jms server的可靠性，任何地方都有可能出现问题，比如网络传输异常，jms server 机器宕了，消费者在消费的时候突然网络异常或者处理消息的时候异常，一切的一切都有可能出现我们想不到的问题。你的工作就是要尽量保证每一个环节丢失消息的可能性。发送端：重连机制、失败储存。
    消费者：重连机制、失败储存。JMS server 尽量做成 HA或者Cluster。参数设置等一切都要仔细研究。不能看到哪个产品好就上了，一定要研究清楚了，测试过，要清楚这些产品在什么情况下面会出现异常，比如网络。磁盘空间，内存不足。压力过大。
      

  7.   

    to csrcom(泥鳅) 
        泥鳅大侠对JMS研究颇有深度啊.弓虽
      

  8.   

    csrcom(泥鳅)大侠：我现在就是在测试ActiveMQ，而且基本上满足要求：首先JMS有它的可靠性保证机制，如它有JMS事务，而且JMS有两种传递模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示该消息一定要被送到目的地，否则会导致应用错误。NON_PERSISTENT 表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。队列可以长久地保存消息直到接收者收到消息。接收者不需要因为担心消息会丢失而时刻和队列保持激活的连接状态，充分体现了异步传输模式的优势。
    接下来，我要测试Broker集群，failover等，也会进行大数据量的压力测试，请各位高手继续指导！
      

  9.   

    csrcom(泥鳅) ，我想请教几个问题：假如有足够的消费者处理某个queue的消息，这个queue会不会成为瓶颈？如果不会成为瓶颈，那么Broker集群主要的作用是否就是HA？
      

  10.   

    Broker集群看你是什么方面得集群，可以做成HA，比如f5设备（这种情况在切换的时候往往会丢失消息）可以做到热备份，当然也可以做成比较低级得load Balance。当你的productor很多、并且不断地发送消息，单一的server 必然会承受不了压力，最终结果是生产缓慢 消费缓慢。这个时候可以考虑 cluster，而非HA。很多消费者对一个队列进行消费，跟很多消费者对很多队列进行消费是有区别的。
    比如你的队列堆积的消息很多，而你想启动很多消费者进行消费，其实没有必要的，要适当的消费者数量。过多是没有意义的，反而会引起性能下降。有时候需要了解一下 server内部的对队列消息持久化的策略、以及线程的调度情况。建议采用cluster 实现 load Balance。
      

  11.   

    谢谢csrcom(泥鳅)：我现在准备用ActiveMQ的集群做测试，这些broker都用同一个数据库保存消息。先用3个producer连续不停的发3k大小的消息，同时也有多个consumer消费消息，有没有瓶颈，测试一下就知道了。
      

  12.   

    我将根据测试结果决定是否集群，如何集群，如何failover等。
      

  13.   

    csrcom(泥鳅)，你先到该问题的另一给分点领分了。http://community.csdn.net/Expert/topic/4820/4820983.xml?temp=.2435724请各位继续关注
      

  14.   

    最近俺也一直在测试Activemq,整体上来说不是很满意，集群还不是很稳定
      

  15.   

    最近俺也在测试Activemq，整体上来说不是很满意，对于集群来说还不稳定