高可用性與故障轉移

這些名詞識別代理程式的設定方式，例如在 broker.xml 中。設定允許將代理程式配對為主要/備份（即代理程式的HA 配對）。

這些形容詞描述代理程式在執行期的行為。例如，您可能有一個被動主要或一個活動備份。

使用共用儲存時，主要和備份伺服器都使用共用檔案系統來共用相同的完整資料目錄。這包括分頁目錄、日誌目錄、大型訊息和繫結日誌。

當主要伺服器發生故障時，它會釋放其在共用日誌上的鎖定，並允許備份伺服器啟動。然後，備份伺服器將從共用檔案系統載入資料，並接受來自用戶端的遠端連線。

通常，這會是某種高效能儲存區域網路 (SAN)。網路附加儲存 (NAS)，如 NFS 掛載，是可行的，但不會提供最佳效能。

共用儲存設定的一個主要優點是主要和備份節點之間不會發生複寫，這表示它在正常運作期間不會因複寫的額外負荷而受到任何效能損失。

共用儲存相對於複寫的一個潛在重大缺點是它需要共用檔案系統，並且當備份伺服器啟動時，它需要從共用儲存載入日誌，這可能需要一些時間，具體取決於儲存中的資料量和儲存的速度。

如果您在正常運作期間需要最高的效能，請取得快速 SAN 的存取權，並處理稍微慢一點的故障轉移（取決於資料量）。

使用複寫時，主要伺服器和備份伺服器不會共用相同的資料目錄。所有資料同步都透過網路進行。因此，主要伺服器接收到的所有 (持久性) 資料都將被複製到備份伺服器。

請注意，在啟動時，備份伺服器首先需要從主要伺服器同步所有現有資料，才能在主要伺服器發生故障時取代它。因此，與使用共用儲存不同，備份伺服器在完成與主要伺服器的資料同步之前，不會完全運作。這需要花費的時間取決於要同步的資料量和連線速度。

由於複寫會在備份伺服器建立資料副本，因此在成功容錯移轉的情況下，備份伺服器的資料會比主要伺服器的資料新。如果您將備份設定為允許故障回復到主要伺服器，那麼當主要伺服器重新啟動時，它將會處於被動狀態，而處於作用中的備份伺服器會將其資料與被動的主要伺服器同步，然後停止以允許被動的主要伺服器再次變成作用中。如果兩個伺服器都關閉，則管理員將必須判斷哪一個伺服器擁有最新的資料。

在共享儲存的情況下，您有幾個選項：

在共享儲存的情況下，也可以在正常伺服器關閉時觸發容錯移轉，若要啟用此功能，請在 primary 或 backup 的 ha-policy 設定中將以下屬性設定為 true，如下所示：

預設情況下，此設定為 false。如果碰巧您已將此設定為 false，但仍然想正常停止伺服器並觸發容錯移轉，則可以使用 管理 中說明的方式，使用管理 API 來執行。

您還可以強制主動備份伺服器在主要伺服器恢復運作時關閉，從而允許主要伺服器自動接管，方法是在 broker.xml 設定檔中設定以下屬性，如下所示：

與共享儲存一樣，可以為仲裁投票和可插拔鎖管理器複製設定設定 allow-failback 選項。

如果 HA 策略是 colocated，則 connectors 和 acceptors 將繼承自建立它的主要伺服器，並根據 backup-port-offset 設定元素的設定進行偏移。如果將其設定為 100 (預設值)，且連接器使用 61616 端口，則對於建立的第一個伺服器，將設定為 61716，對於第二個伺服器，將設定為 61816，依此類推。

有些已設定的連接器可能是用於外部伺服器，因此應排除在偏移之外。例如，叢集連線用於為複製備份伺服器進行仲裁投票的連接器，可以透過將其添加到 ha-policy 設定中來省略偏移，如下所示：

日誌、大型訊息和分頁的目錄將根據 HA 策略進行設定。如果採用共享儲存，則請求伺服器將通知目標伺服器要使用的目錄。如果設定了複製，則目錄將繼承自建立伺服器，但會附加新備份的名稱。

下表列出了共置策略的所有 ha-policy 設定元素：

也可以設定伺服器僅縮減到屬於同一群組的伺服器。這可以透過設定群組來完成，如下所示

在此情況下，只有屬於 my-group 群組的伺服器才會縮減到該群組

也可以透過備份伺服器將縮減與 HA 混合使用。如果設定備份進行縮減，則在容錯移轉發生後，備份伺服器將立即縮減到另一個活動伺服器，而不是完全啟動。最適合的設定是使用 colocated 方法。這表示當您啟動主要伺服器時，它們將自動備份，並且當它們關閉時，它們的訊息將在另一個活動伺服器上可用。典型的設定如下所示

當伺服器停止並準備縮減時，它會向所有用戶端傳送訊息，通知它們它正在縮減到哪個伺服器，然後斷開它們的連線。此時，用戶端將重新連線，但是只有在伺服器完成縮減程序後才會成功。這是為了確保當用戶端重新連線時，任何狀態（例如佇列或交易）都存在。重新連線時會套用正常的重新連線設定，因此這些設定應足夠高，以處理縮減所需的時間。

如果用戶端程式碼處於對伺服器的封鎖呼叫中，等待回應以繼續執行，則當容錯移轉發生時，新會話將不知道正在進行的呼叫。否則，此呼叫可能會永遠掛起，等待永遠不會到來的回應。

為了防止這種情況，Apache ActiveMQ Artemis 會透過使它們擲回 javax.jms.JMSException（如果使用 JMS）或錯誤碼為 ActiveMQException.UNBLOCKED 的 ActiveMQException，來取消封鎖容錯移轉時正在進行的任何封鎖呼叫。由用戶端程式碼來捕獲此例外狀況，並在需要時重試任何操作。

如果被取消封鎖的方法是呼叫 commit() 或 prepare()，則交易將自動回滾，並且 Apache ActiveMQ Artemis 將擲回 javax.jms.TransactionRolledBackException（如果使用 JMS）或錯誤碼為 ActiveMQException.TRANSACTION_ROLLED_BACK 的 ActiveMQException（如果使用核心 API）。

如果會話是交易性的，並且訊息已在目前交易中傳送或確認，則伺服器無法確定在容錯移轉期間是否遺失了已傳送的訊息或確認。

因此，交易將被標記為僅回滾，並且任何後續嘗試提交它都將擲回 javax.jms.TransactionRolledBackException（如果使用 JMS）或錯誤碼為 ActiveMQException.TRANSACTION_ROLLED_BACK 的 ActiveMQException（如果使用核心 API）。

由使用者來捕獲例外狀況，並根據需要執行任何用戶端本地回滾程式碼。無需手動回滾會話，它已經回滾。然後，使用者可以僅在同一會話上再次重試交易操作。

Apache ActiveMQ Artemis 附帶一個功能完善的範例，說明如何執行此操作，請參閱 範例章節。

如果在執行提交呼叫時發生容錯移轉，則伺服器（如先前所述）將取消封鎖呼叫以防止掛起，因為不會傳回任何回應。在這種情況下，用戶端很難確定交易提交是否在發生故障之前實際處理完畢。

為了補救這種情況，用戶端可以簡單地在交易中啟用重複偵測（重複訊息偵測），並在呼叫取消封鎖後再次重試交易操作。如果交易確實已在容錯移轉之前成功提交，則在重試交易時，重複偵測將確保交易中重新傳送的任何持久訊息在伺服器上被忽略，以防止它們被多次傳送。

JMS 提供了一種標準機制，用於非同步取得連線失敗的通知：java.jms.ExceptionListener。請查閱 JMS javadoc 或任何良好的 JMS 教學，以取得有關如何使用此機制的更多資訊。

Apache ActiveMQ Artemis 核心 API 也提供了類似的功能，形式為 org.apache.activemq.artemis.core.client.SessionFailureListener 類別。

任何 ExceptionListener 或 SessionFailureListener 實例都會在連線失敗時始終由 ActiveMQ Artemis 呼叫，**無論** 連線是否成功容錯移轉、重新連線或重新附加。然而，您可以透過 SessionfailureListener 的 connectionFailed 中傳入的 failedOver 旗標，或檢查 javax.jms.JMSException 的錯誤代碼（將會是以下其中一個）來判斷是否發生重新連線或重新附加。

JMSException 錯誤代碼

在某些情況下，您可能不希望自動客戶端容錯移轉，而寧願自己處理任何連線失敗，並在自己的失敗處理程式中編寫自己的手動重新連線邏輯。我們將此定義為應用程式層級容錯移轉，因為容錯移轉是在使用者應用程式層級處理的。

若要實作應用程式層級容錯移轉，如果您使用的是 JMS，則需要在 JMS 連線上設定一個 ExceptionListener 類別。當偵測到連線失敗時，Apache ActiveMQ Artemis 將會呼叫 ExceptionListener。在您的 ExceptionListener 中，您將會關閉舊的 JMS 連線，可能會從 JNDI 查詢新的連線工廠實例，並建立新的連線。

如需應用程式層級容錯移轉的工作範例，請參閱應用程式層級容錯移轉範例。

如果您使用的是核心 API，則程序非常相似：您會在核心 ClientSession 實例上設定一個 FailureListener。