一句话总结： VirtualTopic是为了解决持久化模式下多消费端同时接收同一条消息的问题。
Topic订阅模式缺点，虽然满足1对多同时接收，然而持久化模式下只能有一个持有clientID的消费者连接，不满足持久化需求
简单说来，就是将Topic和Queue相结合，各取所长。
VirtualTopic 就是这样一种存在，对生产者而言它是Topic，对消费者而言它是Queue，内部的处理机制就是由Broker将接收到的消息二次分发给每一个Queue，然后由不同的Queue对应不同的应用实现持久化，不同的消费端只关心并连接到自己的Queue接收消息即可。
VirtualTopic 因为不同消费者会同事收到所有消息，所以会存在重复消费的问题，如果业务上要求只消费一次，需要在业务上做幂等处理。
总结一下：
- 虚拟Topic是一种特殊命名的Topic，系统根据命名规则将该Topic内的消息分发给当前存在的名称对应的Queue，分发是非持久化的，新加入的Queue是接收不到过去的消息的。
- 虚拟Topic还是Topic，不是什么新的存在，具有普通Topic的所有功能，只是名字特殊而已。
- 虚拟Topic的功能完全是中间件本身额外附加的机制，对于生产者和消费者都是无感知的。
- 对于运维人员来说，还是正常监控队列即可，虚拟Topic是非持久化的，不存在积压。
