參考網址：
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名稱不同（前綴不同），所以不同的應用中都可以接收到全部的消息。每個客戶端相當於一個持久訂閱者，而且這個客戶端可以使用多個消費者共同來承擔消費任務。