ActiveMQ VirtualTopic

参考网址：

http://activemq.apache.org/virtual-destinations.html

http://blog.csdn.net/kimmking/article/details/9773085

实际场景：

整个项目中，自己处于consumer端，与另外一个consumer共同监听topic消息，发送的是VirtualTopic消息。

原来使用的 VirtualTopic.***监听不到消息，后请教同组大神，才知道要改成Consumer.***.VirtualTopic.***，监听到消息。

原因：

ActiveMQ支持的虚拟Destinations分为有两种，分别是

Ø  虚拟主题（Virtual Topics）

Ø  组合 Destinations（CompositeDestinations）

这两种虚拟Destinations可以看做对简单的topic和queue用法的补充，基于它们可以实现一些简单有用的EIP功能，虚拟主题类似于1对多的分支功能+消费端的cluster+failover，组合Destinations类似于简单的destinations直接的路由功能。

虚拟主题（Virtual Topics）

ActiveMQ中，topic只有在持久订阅（durablesubscription）下是持久化的。存在持久订阅时，每个持久订阅者，都相当于一个持久化的queue的客户端，它会收取所有消息。这种情况下存在两个问题：

1. 同一应用内consumer端负载均衡的问题：同一个应用上的一个持久订阅不能使用多个consumer来共同承担消息处理功能。因为每个都会获取所有消息。queue模式可以解决这个问题，broker端又不能将消息发送到多个应用端。所以，既要发布订阅，又要让消费者分组，这个功能jms规范本身是没有的。

2. 同一应用内consumer端failover的问题：由于只能使用单个的持久订阅者，如果这个订阅者出错，则应用就无法处理消息了，系统的健壮性不高。

为了解决这两个问题，ActiveMQ中实现了虚拟Topic的功能。使用起来非常简单。

对于消息发布者来说，就是一个正常的Topic，名称以VirtualTopic.开头。例如VirtualTopic.TEST。

对于消息接收端来说，是个队列，不同应用里使用不同的前缀作为队列的名称，即可表明自己的身份即可实现消费端应用分组。例如Consumer.A.VirtualTopic.TEST，说明它是名称为A的消费端，同理Consumer.B.VirtualTopic.TEST说明是一个名称为B的客户端。可以在同一个应用里使用多个consumer消费此queue，则可以实现上面两个功能。又因为不同应用使用的queue名称不同（前缀不同），所以不同的应用中都可以接收到全部的消息。每个客户端相当于一个持久订阅者，而且这个客户端可以使用多个消费者共同来承担消费任务。