一句話總結： 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是非持久化的，不存在積壓。
