ActiveMQ与虚拟通道

郑重提示,本文转载自http://shift-alt-ctrl.iteye.com/blog/2065436

 

ActiveMQ提供了虚拟通道的特性(Virtual Destination),它允许一个逻辑通道(logical destination)映射成一个或者多个物理通道(physical destination);它可以非常灵活的解决"消息整合"方面的问题,它可以实现:

    1) 提供了VirtualTopic特性,可以让一个订阅者的消息列表,作为Queue来消费。

    2) 提供了Composite特性,可以把一个逻辑通道中的消息,转发到任意多的物理通道中。

 

一. VirtualTopic

   Topic最大的限制就是同一个ClientId的订阅者,任何时刻只能有一个活跃。所以我们在分布式部署时,就会很麻烦,比如一个应用部署成多个实例,且它们都有相同的Topic Consumer配置,那么意味着

一个实例部署成功后,其它的实例都会因为无法订阅Topic而导致故障;同时也意味着,如果这个Topic Consumer失效后,我们不能自动让其他Consumer的接管它。但是Queue却没有这些限制,因为Queue可以同时有任意多个消费者,它们可以并发的消费消息,从而实现“负载均衡”。如果我们期望Topic也能如此,那么可以用VirtualTopic。

<broker xmlns="http://activemq.apache.org/schema/core">  
  <destinationInterceptors>  
    <virtualDestinationInterceptor>  
      <virtualDestinations>  
        <virtualTopic name=">" prefix="VConsumers.*." selectorAware="false"/>  
      </virtualDestinations>  
    </virtualDestinationInterceptor>  
  </destinationInterceptors>  
</broker>  

 

    对于所有的VirtualTopic,它们的namespace一定是"VirtualTopic.",Broker将会根据此namespace来判定逻辑通道是否为VirtualTopic,反过来说,如果你希望一个逻辑通道是一个VirtualTopic,那么它必须以“VirtualTopic.”作为前缀。比如“VirtualTopic.order”,那么它就是一个VirtualTopic,它的物理通道名称为"order"。

 

    对于Producer端,需要按照正常的Topic发送消息,通道名称为逻辑通道全名:

Topic topic = session.createTopic("VirtualTopic.order");  
MessageProducer producer = session.createProducer(topic);  
//producer.send(message); 

 

     VirtualTopic对Consumer而言,是一个逻辑的Queue,Queue的全名有上述配置文件中的“prefix” + Client标识 + 逻辑虚拟通道;假如“Client标识”为"dbcenter"【相当于ClientId】,用来订阅Order消息,那么最终逻辑Queue的全名为:"VConsumers.dbcenter.VirtualTopic.order",其中需要注意prefix中的"*"占位符就是用来替换“Client标识”的;Broker端默认的prefix为"Consumer.*."。当然我们还可以postfix【后缀】,不过通常没有必要。

Queue queue = session.createQueue("VConsumers.dbcenter.VirtualTopic.order");  
MessageConsumer consumer = session.createConsumer(queue); 

 

    对于Order通道而言,“dbcenter”相当于是一个订阅者;Broker将dbcenter订阅的消息转发到了“VConsumers.dbcenter.VirtualTopic.order”队列中;最重要的一点,这个虚拟Queue完全具有队列的所有特性,它的Consumer可以并行消费。

 

    其中还有一个重要的参数"selectorAware",它表示从Topic中将消息转发给Queue时,是否关注Consumer的selector情况。如果为false,那么Topic中的消息全部转发给Queue,否则只会转发匹配Queue Consumer的selector的消息。需要非常注意,当selectorAware为true时,如果消息不匹配任何selector或者Queue中没有任何Consumer活跃,那么消息将不会转发给Queue。

 

     VirtualTopic仍然可以被正常的订阅者消费,即:

Topic topic = session.createTopic("VirtualTopic.order");  
TopicSubscriber subscriber = session.createDurableSubscriber(topic,"dbcenter"); 

 

     同时需要注意,VirtualTopic只会转发“Client标识”注册之后的消息,且即使Queue消费了消息,VirtualTopic中的消息仍然不会被删除(看起来仍然是Dequeued=0),对于Broker而言,逻辑Queue不被认为是一个“Durable Subscriber”,只有真正的Subscriber消费消息后,Topic中的消息才会Dequeue。不过消息Dequeue后,不会影响Queue中的消息,因为这是基于Copy的。

 

    到目前为止,我尚不清楚,如果VirtualTopic中没有真正的Subscriber,这些消息该如何Dequeue。

 

    当真正的subscriber和Queue都同时存在VirtualTopic中的时候,而且你的broker架构采用了“forward-brige”结构,那么你需要增加如下配置来避免消息的重复转发问题。在forward-brige架构中,任何通道中的消息都会forward到其他network node中(其他broker上),当然这个虚拟的Queue的消息也不例外。

<networkConnectors>  
  <networkConnector uri="static://(tcp://localhost:61617)">  
    <excludedDestinations>  
        <!-- prefix和VirtualTopic保持一致  -->
        <queue physicalName="VConsumer.*.VirtualTopic.>"/>  
    </excludedDestinations>  
  </networkConnector>  
</networkConnectors>

 

 二. Composite Destinations

    复合通道,它允许一条消息在多个物理通道间转发,就像一个通道映射成多个一样(one-many);比如复合通道A,映射成B和C,那么发往A的消息会同时转发给B和C,那么消费者可以直接通过B或者C获取消息;

这是一种实现消息复制转发、通道映射的便捷办法。复合通道包括CompositeQueue和CompositeTopic两种。

<broker persistent="false" useJmx="false" xmlns="http://activemq.apache.org/schema/core">  
    <destinationInterceptors>  
      <virtualDestinationInterceptor>  
        <virtualDestinations>  
          <compositeQueue name="order">  
            <forwardTo>  
              <queue physicalName="order.dbcenter" />  
              <topic physicalName="order.statistic" />  
            </forwardTo>  
          </compositeQueue>  
 <!--   
 <compositeTopic name="order" forwardOnly="false">  
            <forwardTo>  
              <queue physicalName="order.dbcenter" />  
              <topic physicalName="order.statistic" />  
            </forwardTo>  
          </compositeTopic>  
 -->  
        </virtualDestinations>  
      </virtualDestinationInterceptor>  
    </destinationInterceptors>  
   
  </broker>

  

 

    上述配置forwardOnly属性表示发往CompositeQueue中的消息是否“仅仅转发,而不本地保留”,如果forwardOnly为true,那么消息将不会在order队列中保留,即order队列中不会有任何消息。如果为false,那么消息将会转发完成后,添加到order中,消费者仍然可以消费order队列中的消息。无论是Compsite通道还是转发的通道,它们和普通的通道没有任何区别,开发者仍然可以像使用普通的通道一样使用它们(消费消息和发送消息)。

  

    很多时候,我们希望在转发消息时,能够使用selector,此时我们可以使用filteredDestination,这样我们可以消息转发时控制消息。

<compositeQueue name="MY.QUEUE">  
    <forwardTo>  
         <filteredDestination selector="orderType = 1" queue="food.order"/>  
        <filteredDestination selector="status = 1" topic="order.statistic"/>  
    </forwardTo>  
</compositeQueue>

  

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: ActiveMQ和RabbitMQ都是流行的消息队列软件,它们的主要区别在于: 1. 语言支持:ActiveMQ是用Java编写的,而RabbitMQ是用Erlang编写的,因此RabbitMQ在处理高并发和高吞吐量时更加出色。 2. 协议支持:ActiveMQ支持多种协议,包括OpenWire、Stomp、AMQP和MQTT等,而RabbitMQ主要支持AMQP协议。 3. 可靠性:RabbitMQ在消息传递方面更加可靠,因为它使用了一些高级特性,如事务和确认机制。 4. 性能:RabbitMQ的性能比ActiveMQ更好,因为它使用了一些高级技术,如预取和流控制等。 总之,如果你需要处理高并发和高吞吐量的消息传递,那么RabbitMQ可能是更好的选择。如果你需要支持多种协议和更灵活的配置选项,那么ActiveMQ可能更适合你。 ### 回答2: ActiveMQ和RabbitMQ都是开源的消息中间件,它们都有自己独特的优势和适用场景。 ActiveMQ是基于Java的消息队列系统,它支持Java Messaging Service(JMS)标准,并且可以通过许多编程语言访问。ActiveMQ支持多种协议,如AMQP、MQTT、OpenWire和STOMP,且其性能较高,适合处理大量消息。ActiveMQ还提供了许多高级功能,如分布式事务、消息持久性、监视和管理等。此外,ActiveMQ还具有高可用性、冗余性和容错性等特点。 而RabbitMQ则是基于Erlang语言开发的,它支持AMQP(Advanced Message Queueing Protocol)和许多高级消息队列特性,如异步通信、消息确认、消息持久性和发布/订阅模式等。RabbitMQ还支持多种客户端库,包括Java、.NET、Python、Ruby和PHP等,适用于各种不同的应用场景。RabbitMQ还提供了许多插件和扩展,如消息转发器、集群和管理插件等,可以适应大量数据流量的需求。 在实际应用中,选择使用哪种消息队列系统取决于应用的具体需求和场景。如果需要高性能、高可用性、高容错性和高度分布式,则可以选择ActiveMQ。如果需要可扩展性、弹性、多语言支持和丰富插件,则可以选择RabbitMQ。当然,在选择之前,需要对这两个开源项目的详细了解和比较,以便能够选择最适合特定应用场景的消息队列系统。 ### 回答3: ActiveMQ和RabbitMQ是两种主要的消息队列中间件。它们在功能和性能方面均有很大的不同,这里将会深入探讨它们之间的差异。 首先是它们的架构和工作原理。ActiveMQ的架构是基于Java消息服务规范的,可以在Java、C++、Python等多种语言中运行。RabbitMQ是基于AMQP协议的,它是一种面向消息的中间件协议,用于消息传递、路由和连接的标准。ActiveMQ使用JMS作为应用程序接口,而RabbitMQ在AMQP基础上提供了自己的AMQP实现代码。所以,ActiveMQ更适合面向Java开发人员,而RabbitMQ适合更广泛的应用场景。 其次是它们的性能和可扩展性。ActiveMQ具有较好的水平扩展性,可以构建集群,并且可以将消息持久化到磁盘中以进行高可靠性。但是它的性能往往不如RabbitMQ。RabbitMQ具有出色的消息处理性能,并能够处理大量的并发请求。它使用预取机制来提高性能,这意味着RabbitMQ将尽可能提供更多消息,使客户机可以更快地处理它们。 再次是它们的功能和应用场景。ActiveMQ提供了许多高级功能,如消息过滤、消息路由、消息事务等,非常适合大规模企业级应用程序。RabbitMQ适用于需要高吞吐量的场景,如物联网、游戏、金融等领域。RabbitMQ还提供了一些高级功能,如发布/订阅、主题路由等。 总的来说,ActiveMQ和RabbitMQ都有各自的优点和缺点,开发者应该根据自己的特定需求选择适合的中间件。如果需要建立高度可靠的企业应用程序,应选择ActiveMQ。如果需要高可扩展性和高吞吐量的大规模应用程序,则应使用RabbitMQ。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值