一句话总结： VirtualTopic是为了解决持久化模式下多消费端同时接收同一条消息的问题。
现实中多出现这样一个场景：
生产端产生了一笔订单，作为消息MessageOrder发了出去。
这笔订单既要入订单系统归档，又要入结算系统收款，那怎么办呢？
现在分析该消息的需求：
持久化：订单很重要，丢了可不行
同时接收：既要归档，又要结算
生产端只需向一个Destination发送：一把钥匙开一把锁，保持发送的一致性，否则容易乱套
方案A: 使用Topic订阅模式，虽然满足1对多同时接收，然而持久化模式下只能有一个持有clientID的消费者连接，不满足持久化需求
方案B: 使用单队列，队列是1对1模式，消息只能给一个消费者，不满足同时接收的需求
方案C: 使用多队列，显然生产者不太愿意一条消息发送很多次，分别发送给不同的队列，万一队列A发送成功，队列B发送失败怎么办？一致性无法保证，容易乱套
所以，JMS现有规范无法解决这个问题，于是，ActiveMQ使用VirtualTopic作为JMS规范的补充登场。
那VirtualTopic如何同时满足上述需求呢？
简单说来，就是将Topic和Queue相结合，各取所长。
在方案C中，我们发现使用多队列可以满足持久化和同时接收两个需求，但意味着生产者要发送消息给多个队列，一致性不好，那既然生产者不想分发，那么由Broker来分发可好？
VirtualTopic就是这样一种存在，对生产者而言它是Topic，对消费者而言它是Queue，内部的处理机制就是由Broker将接收到的消息二次分发给每一个Queue，然后由不同的Queue对应不同的应用实现持久化，不同的消费端只关心并连接到自己的Queue接收消息即可。
现在来复盘开始提出的场景：
显然，三个需求都得到了解决。
总结一下：
1. 虚拟Topic是一种特殊命名的Topic，系统根据命名规则将该Topic内的消息分发给当前存在的名称对应的Queue，分发是非持久化的，新加入的Queue是接收不到过去的消息的。
2. 虚拟Topic还是Topic，不是什么新的存在，具有普通Topic的所有功能，只是名字特殊而已。
3. 虚拟Topic的功能完全是中间件本身额外附加的机制，对于生产者和消费者都是无感知的。
4. 对于运维人员来说，还是正常监控队列即可，虚拟Topic是非持久化的，不存在积压。