拓撲
ActiveMQ Classic 支援多種不同的部署拓撲，以及 協定 和傳輸格式。 下圖顯示了一個由多種不同拓撲組成的聯合 Broker 網路。
選擇哪種拓撲取決於您。 我們現在將更詳細地描述其中一些協定。
VM 內部
在單元測試時，將 JMS 通訊限制在單個 JVM 內是一個有用的選項。為此，請使用協定
vm://127.0.0.1
您可以將 VM 協定劃分為不同的群組 - 例如，如果您想在同一個 JVM 內擁有邏輯上不同的 JMS 網路，您可以使用不同的 URI 對網路進行分組。 例如：
vm://127.0.0.1/foo
這將確保不同的區段不會互相干擾。 雖然我們通常使用唯一的主題和佇列目的地，以便所有流量都可以在同一個邏輯網路上順利共存。
客戶端-伺服器
對於需要從發布/訂閱到基於佇列的通訊等各種通訊選項的大量客戶端來說，這可能是最有效率和最快的解決方案。 通常，客戶端會使用協定（通常是 TCP 或 SSL，但也可能是 NIO 或其他協定）與訊息 Broker 連線。
我們可以將客戶端跨多個 Broker 進行負載平衡，並提供 Broker 故障轉移，以便擁有一個具有 HA 的邏輯 Broker 叢集。
例如：
tcp://somehost:port
或是使用 SSL：
ssl://somehost:port
您可以使用 探索 來查找可連線的可用 Broker，這使得無縫連線到 Broker 叢集變得更加容易。
內嵌 Broker
這在邏輯上等同於客戶端-伺服器，但某些（或所有）客戶端包含本地嵌入的 Broker。 因此，客戶端和伺服器 (Broker) 之間的通訊都在同一個 JVM 內，因此不使用真實網路 - 儘管 Broker 可能會與其他 Broker 或連線到它的客戶端進行通訊。
這可以避免從生產者到 Broker 再到消費者所需的額外躍點 - 這對於 RMI/RPC 風格的情況來說是一個很好的最佳化，在這種情況下，您希望獲得點對點網路的效能優勢（減少延遲），但同時具備靈活的訊息傳遞架構的可擴展性。
內嵌 Broker 也可以簡化部署選項，因為它可以減少一個要執行的程序。
內嵌 Broker 的另一個用例是提供與每個服務的儲存和轉發隔離 - 這樣遠端 Broker 就可以在不影響具有內嵌 Broker 的服務的情況下愉快地失敗。 例如，整個網路可能會失敗，但服務可以繼續將訊息發布到其內嵌 Broker。
您可以在此處找到如何 設定內嵌 Broker
對等
這允許建立沒有伺服器的基於對等的叢集 - 只有客戶端連線在一起。
有多種方法可以實現對等 JMS 網路。 一個簡單的方法是僅使用多點傳輸進行通訊； 然後，同一個多點傳輸位址上的所有節點都會收到所有訊息，並且本地嵌入的訊息 Broker 會將訊息路由到必要的 MessageConsumer。
我們目前有 3 種多點傳輸協定可供選擇
- 多點傳輸
- jgroups：使用 JGroups 程式庫實現可靠的多點傳輸
- jrms：使用 Sun 的 JRMS 程式庫實現可靠的多點傳輸
多點傳輸在開發中非常有用，但通常您可能希望在生產中停用此功能，並在特定機器上固定已知的伺服器。 通常，基於 Socket 的通訊（使用點播）速度更快、更適合大量處理 - 特別是在 Java 上 - 因此我們傾向於建議主要使用多點傳輸進行探索，並使用 TCP/SSL 進行大量訊息傳遞。
通常，我們可以使用對等拓撲作為引導程序來建立客戶端和 Broker 的叢集，然後將伺服器自動部署到叢集中，以實現真正的網格風格網路。
因此，您可以使用 探索 以及獨立的 Broker 或使用內嵌 Broker 來獲得基於對等網路的效果。
JXTA
我們有一個 JXTA 傳輸，它將使用完整的 JXTA 堆疊來協商 NAT 並跨防火牆等等，以建立真正的基於對等的 JMS 網路。
jxta://hostname:port
目前，您需要執行一個伺服器，每個人都透過 JXTA 連線到該伺服器。 我們尚未使用 JXTA 建立純粹的對等網路
