Apache ActiveMQ Artemis 是一個非同步訊息傳遞系統，是訊息導向中介軟體的一個例子，在本書的其餘部分，我們將簡單地稱它們為訊息傳遞系統。
我們將首先簡要概述訊息傳遞系統的功能、它們的用途以及您在訊息傳遞領域會聽到的各種概念。
如果您已經熟悉訊息傳遞系統是什麼以及它的功能，則可以跳過本章。
1. 一般概念
訊息傳遞系統讓您可以鬆散地耦合異質系統，同時通常提供可靠性、交易和許多其他功能。
與基於遠端程序呼叫 (RPC) 模式的系統不同，訊息傳遞系統主要使用非同步訊息傳遞模式，請求和回應之間沒有緊密的關係。大多數訊息傳遞系統也支援請求-回應模式，但這不是訊息傳遞系統的主要功能。
從端到端將系統設計為非同步，可以讓您真正利用硬體資源，最大限度地減少在 IO 操作上阻塞的執行緒數量，並充分利用網路頻寬。使用 RPC 方法，您必須等待每個請求的回應，因此會受到網路往返時間或網路延遲的限制。使用非同步系統，您可以在不同方向上流水線式傳輸訊息流，因此會受到網路頻寬而不是延遲的限制。這通常可以讓您建立效能更高的應用程式。
訊息傳遞系統將訊息的發送者與訊息的消費者分離。訊息的發送者和消費者完全獨立，彼此之間一無所知。這讓您可以建立靈活、鬆散耦合的系統。
通常，大型企業會使用訊息傳遞系統來實作訊息匯流排，該匯流排將異質系統鬆散地耦合在一起。訊息匯流排通常構成企業服務匯流排 (ESB) 的核心。使用訊息匯流排來分離不同的系統可以讓系統更容易成長和適應。它還能更靈活地新增新系統或淘汰舊系統，因為它們彼此之間沒有脆弱的依賴關係。
2. 訊息傳遞風格
2.1. 點對點
使用這種訊息傳遞類型，您可以將訊息傳送到佇列。然後，訊息通常會被持久化以確保傳遞，然後在稍後，訊息傳遞系統會將訊息傳遞給消費者。然後，消費者會處理訊息，完成後會確認訊息。一旦訊息被確認，它就會從佇列中消失，無法再次傳遞。如果系統在訊息伺服器收到消費者的確認之前崩潰，那麼在恢復時，該訊息將可再次傳遞給消費者。
使用點對點訊息傳遞，佇列上可以有多個消費者，但特定訊息最多只會被其中一個消費者使用。佇列的發送者（也稱為生產者）與佇列的接收者（也稱為消費者）完全分離，他們不知道彼此的存在。
點對點訊息傳遞的經典範例是公司書籍訂購系統中的訂單佇列。每個訂單都表示為一個訊息，該訊息會被傳送到訂單佇列。假設有多個前端訂購系統會將訂單傳送到訂單佇列。當訊息到達佇列時，它會被持久化，這可確保如果伺服器崩潰，訂單不會遺失。我們也假設訂單佇列上有許多消費者，每個消費者都代表訂單處理元件的一個實例，這些實例可以在不同的實體機器上，但都從同一個佇列使用。訊息傳遞系統會將每個訊息傳遞給其中一個且只有一個訂單處理元件。不同的訊息可以由不同的訂單處理器處理，但單一訂單只會由一個訂單處理器處理，這可確保訂單不會被處理兩次。
當訂單處理器收到訊息時，它會執行訂單、將訂單資訊傳送到倉庫系統，然後使用訂單詳細資訊更新訂單資料庫。完成後，它會確認訊息，以告知伺服器訂單已處理完畢，可以忘記了。通常，傳送至倉庫系統、在資料庫中更新和確認將在單一交易中完成，以確保ACID 屬性。
2.2. 發布-訂閱
使用發布訂閱訊息傳遞，許多發送者可以將訊息傳送到伺服器上的實體，通常稱為主題（例如，在 JMS 世界中）。
主題上可以有多個訂閱，訂閱只是主題消費者的另一個詞。每個訂閱都會收到傳送到主題的每個訊息的副本。這與每個訊息僅由單一消費者使用的訊息佇列模式不同。
訂閱可以選擇性地設為持久，這表示它們會保留傳送到主題的每個訊息的副本，直到訂閱者使用它們，即使伺服器在這之間崩潰或重新啟動。非持久訂閱的持續時間最多只會在建立它們的連線的生命週期內。
發布訂閱訊息傳遞的一個範例是新聞饋送。當世界各地不同的編輯建立新聞文章時，它們會被傳送到新聞饋送主題。世界各地有許多訂閱者有興趣接收新聞項目，每個訂閱者都會建立訂閱，而訊息傳遞系統會確保將每個新聞訊息的副本傳遞給每個訂閱。
3. 傳遞保證
大多數訊息傳遞系統的一個關鍵功能是可靠訊息傳遞。透過可靠訊息傳遞，伺服器會保證訊息會被傳遞一次且僅一次給佇列的每個消費者或主題的每個持久訂閱，即使在系統故障的情況下也是如此。這對於許多企業至關重要；例如，您不希望您的訂單被多次履行或任何訂單遺失。
在其他情況下，您可能不在乎一次且僅一次的傳遞保證，並且樂意處理重複的傳遞或遺失的訊息，這方面的一個範例可能是瞬時的股票價格更新，這些更新很快就會被同一股票的下一次更新所取代。訊息傳遞系統允許您設定您需要的傳遞保證。
4. 交易
訊息傳遞系統通常支援在單一本地交易中傳送和確認多個訊息。Apache ActiveMQ Artemis 還支援將訊息的傳送和確認作為大型全域交易的一部分，使用 XA 的 Java 對應：JTA。
5. 持久性
訊息可以是持久的或非持久的。持久訊息將被持久化到永久儲存空間，並且可以在伺服器故障或重新啟動後繼續存在。非持久訊息無法在伺服器故障或重新啟動後繼續存在。持久訊息的範例可能是訂單或交易，它們不能遺失。非持久訊息的範例可能是股票價格更新，它是暫時的，不需要在重新啟動後繼續存在。
6. 訊息傳遞 API
用戶端應用程式如何與訊息傳遞系統互動以傳送和使用訊息？
一些訊息傳遞系統會提供自己的專有 API，讓用戶端透過這些 API 與訊息傳遞系統通訊。
也有一些使用訊息傳遞系統的標準方式，以及這個領域中一些新興的標準。讓我們簡要地了解一下這些。
6.1. JMS & Jakarta Messaging
JMS 在歷史上是 Oracle Java EE 規格的一部分。然而，在 2017 年，控制權轉移到了 Eclipse 基金會，現在它被稱為 Jakarta Messaging，它是 Jakarta EE 的一部分。
它是一個 Java API，封裝了訊息佇列和發布訂閱訊息傳遞模式。它是一個最低公分母規格，也就是說，它旨在封裝在建立時可用的現有訊息傳遞系統的常見功能。
它是一個非常受歡迎的 API，並且由大多數訊息傳遞系統實作。它僅適用於執行 Java 的用戶端。
它沒有定義標準的連線格式，它只定義了一個程式化 API，因此不同廠商的用戶端和伺服器無法直接互通，因為每個都會使用廠商自己的內部連線協定。
Apache ActiveMQ Artemis 提供了完全符合JMS 1.1 和 2.0 以及 Jakarta Messaging 2.0 和 3.0 的用戶端實作。
6.2. 系統特定 API
許多系統會提供自己的程式化 API，以便與訊息系統互動。這樣做的好處是，它可以讓完整的系統功能暴露給客戶端應用程式。像 JMS 這樣的 API 通常不夠豐富，無法暴露大多數訊息系統提供的所有額外功能。
如果您希望存取 JMS API 無法提供的功能，Apache ActiveMQ Artemis 提供了自己的核心客戶端 API 供客戶端使用。
請參閱核心，以了解如何將核心 API 與 Apache ActiveMQ Artemis 一起使用。
7. 高可用性
高可用性 (HA) 指的是系統在一個或多個伺服器發生故障後應保持運作。不同訊息系統對 HA 的支援程度有所不同。
Apache ActiveMQ Artemis 提供自動故障轉移功能，當伺服器發生故障時，您的連線會自動重新連線到備份伺服器。
如需更多關於 HA 的資訊，請參閱高可用性和故障轉移。
8. 叢集
許多訊息系統允許您建立稱為叢集的訊息伺服器群組。叢集允許將發送和接收訊息的負載分散到多個伺服器上。這讓您可以透過向叢集中新增伺服器來水平擴展您的系統。
不同訊息系統對叢集的支援程度有所不同，有些系統的叢集相當基本，叢集成員之間幾乎互不感知。
Apache ActiveMQ Artemis 提供高度可配置的先進叢集模型，訊息可以根據每個節點上的消費者數量以及它們是否準備好接收訊息，在叢集中的伺服器之間智能地進行負載平衡。
Apache ActiveMQ Artemis 還具有在叢集節點之間自動重新分配訊息的能力，以防止任何特定節點上的資源匱乏。
如需有關叢集的完整詳細資訊，請參閱叢集。
9. 橋接和路由
一些訊息系統允許將隔離的叢集或單個節點橋接在一起，通常是透過像廣域網路 (WAN) 或網際網路這樣不可靠的連線。
橋接通常會從一個伺服器上的佇列中接收訊息，並將訊息轉發到另一個伺服器上的另一個佇列。橋接可以處理不可靠的連線，並在連線重新可用時自動重新連線。
Apache ActiveMQ Artemis 橋接可以配置過濾器表達式，以僅轉發特定訊息，並且還可以掛載轉換。
Apache ActiveMQ Artemis 還允許在伺服器端配置中設定佇列之間的路由。這允許建立複雜的路由網路，將訊息從一個目的地轉發或複製到另一個目的地，形成一個相互連接的代理程式的全球網路。