ActiveMQ与虚拟通信

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。

    默认情况下，ActiveMQ开启了VirtualTopic特性，此时Topic的默认命名空间为“VirtualTopic.>”，即命名模式为“VirtualTopic.<topicName>”，比如“VirtualTopic.order”；那么对于consumer而言，对应的Queue命名模式为“Consumer.*.VirtualTopic.<topicName>”，其中“*”的语义类似于clientId。代码示例如下：

Java代码

 

1. //物理通道名称为：order  
2.   
3. //producer端  
4. Topic top = session.createTopic("VirtualTopic.order");  
5. producer = session.createProducer(top);  
6.   
7. //consumer端  
8. //其中dbcenter为clientId  
9. //此后我们可以创建多个consumer，它们使用同一个clientId  
10. Queue queue = session.createQueue("Consumer.dbcenter.VirtualTopic.order");  
11. MessageConsumer consumer = session.createConsumer(queue);  

    当然，ActiveMQ的默认配置，还不能满足我们的日常需求，比如：

    1）一个现有的topic，如果需要转换为VirtualTopic

    2）希望物理topic与虚拟topic可以并存使用，比如一个Topic，已经有多个consumer，但是新加入了一个consumer，且此consumer需要使用VirtualTopic模式否则无法完成正常业务，如果将现有的producer和consumer的Topic地址都调整一遍是不太现实的，那么此时我们就需要通过调整配置来完成，即自定义VirtualTopic。（如下配置，将所有的topic映射为VirtualTopic）

Java代码

 

1. <broker xmlns="http://activemq.apache.org/schema/core">  
2.   <destinationInterceptors>  
3.     <virtualDestinationInterceptor>  
4.       <virtualDestinations>  
5.         <virtualTopic name=">" prefix="Consumer.*." selectorAware="false"/>  
6.       </virtualDestinations>  
7.     </virtualDestinationInterceptor>  
8.   </destinationInterceptors>  
9. </broker>  

Java代码

 

1. <!-- ActiveMQ的默认方式，等效于如下配置 -->  
2. <virtualTopic name="VirtualTopic.>" prefix="Consumer.*." selectorAware="false"/>  

    调整配置之后，我们的producer端代码不需要任何修改，即现有的物理Topic已经被映射为虚拟topic，且topic命名中无需添加“VirtualTopic.”前缀。代码示例如下：

Java代码

 

1. //producer端  
2. Topic top = session.createTopic("order");  
3. producer = session.createProducer(top);  
4.   
5. //consumer端  
6. //其中dbcenter为clientId  
7. //此后我们可以创建多个consumer，它们使用同一个clientId  
8. Queue queue = session.createQueue("Consumer.dbcenter.order");  
9. MessageConsumer consumer = session.createConsumer(queue);  

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

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

     此外，VirtualTopic仍然可以被正常的订阅者消费（默认配置情况下），即：

Java代码

 

1. Topic topic = session.createTopic("VirtualTopic.order");  
2. 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的消息也不例外。

Java代码

 

1. <networkConnectors>  
2.   <networkConnector uri="static://(tcp://localhost:61617)">  
3.     <excludedDestinations>  
4.         <!-- prefix和VirtualTopic保持一致  
5.         <queue physicalName="Consumer.*.VirtualTopic.>"/>  
6.     </excludedDestinations>  
7.   </networkConnector>  
8. </networkConnectors>  

 二. Composite Destinations

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

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

Java代码

 

1. <broker persistent="false" useJmx="false" xmlns="http://activemq.apache.org/schema/core">  
2.     <destinationInterceptors>  
3.       <virtualDestinationInterceptor>  
4.         <virtualDestinations>  
5.           <compositeQueue name="order">  
6.             <forwardTo>  
7.               <queue physicalName="order.dbcenter" />  
8.               <topic physicalName="order.statistic" />  
9.             </forwardTo>  
10.           </compositeQueue>  
11.  <!--   
12.  <compositeTopic name="order" forwardOnly="false">  
13.             <forwardTo>  
14.               <queue physicalName="order.dbcenter" />  
15.               <topic physicalName="order.statistic" />  
16.             </forwardTo>  
17.           </compositeTopic>  
18.  -->  
19.         </virtualDestinations>  
20.       </virtualDestinationInterceptor>  
21.     </destinationInterceptors>  
22.    
23.   </broker>  

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

  

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

Java代码

 

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