AMQP 的訊息遞送可靠性

IBM® MQ Light API 有四個特性可讓您控制與 MQ Light 及 AMQP 應用程式之間的訊息遞送可靠性。

它們是：

訊息服務品質 (QOS)

MQ Light API 提供兩種服務品質:

您可以選擇要發佈者和訂閱者使用的服務品質。

如果您使用 MQ Light 用戶端，請將用戶端或訂閱 qos 選項設為 QOS_AT_MOST_ONCE 或 QOS_AT_LEAST_ONCE。

如果您使用不同的 AMQP 用戶端，請視您要達到的服務品質而定，將傳送訊框 (適用於發佈者) 或處置訊框 (適用於訂閱者) 的 settled 屬性設為 true 或 false。

服務品質會決定何時從交談的 sending 端捨棄訊息。

正在發佈

如果發佈者選擇 QOS 0 (最多一次) ，在捨棄其訊息副本之前，發佈者不會等待來自佇列管理程式的確認通知。

如果在傳送完成之前與佇列管理程式的連線失敗，訂閱者可能不會收到訊息。

如果發佈者選擇 QOS 1 (至少一次) ，發佈者會等待佇列管理程式確認訊息已寫入訂閱者佇列，然後再捨棄其訊息副本。

如果在傳送期間與佇列管理程式的連線失敗，發佈者會在重新連接至佇列管理程式之後重新傳送訊息。

如果訂閱者選擇 QOS 0 ，佇列管理程式在捨棄其訊息副本之前不會等待來自訂閱者的確認通知。

如果訂閱者的連線在訂閱者收到訊息之前失敗，則該訊息可能會遺失。

如果訂閱者選擇 QOS 1 ，佇列管理程式會先等待來自訂閱者的確認通知，再捨棄其訊息副本。

如果訂閱者的連線在訂閱者收到訊息之前失敗，佇列管理程式會保留該訊息。當佇列管理程式重新連接時，佇列管理程式會將訊息重新傳送給訂閱者，如果訂閱是共用的，則會重新傳送給另一個訂閱者。

如果訂閱者選擇 QOS 1 (至少一次) ，則必須確認在佇列管理程式捨棄其副本之前收到每一則訊息。訂閱者可以決定何時確認訊息。

當 auto-confirm 設為 true時，一旦用戶端透過網路順利接收訊息， MQ Light 用戶端就會自動確認每一個訊息的遞送。

這可確保如果網路失敗，訊息會重新遞送至應用程式。不過，如果應用程式在確認訊息的 MQ Light 用戶端與處理訊息的應用程式之間失敗，應用程式仍有可能遺失訊息。

當 auto-confirm 設為 false時， MQ Light 用戶端不會自動確認訊息的遞送，但會將它留給應用程式來決定何時應該確認。

這可讓應用程式在向佇列管理程式確認訊息現在已處理且可以捨棄之前，先更新外部資源 (例如資料庫或檔案)。

當應用程式訂閱時，它會選擇在應用程式中斷連線之後是否繼續存在訂閱，以及儲存該訂閱之訊息的目的地。

MQ Light 訂閱選項 ttl 用來指定在應用程式中斷連線之後訂閱繼續存在的時間 (毫秒)。如果應用程式在此時間之前重新連接，則會回復訂閱，且應用程式可以繼續耗用來自該訂閱的訊息。

如果在沒有應用程式重新連接的情況下過了存活時間期間，則會移除訂閱，且會遺失儲存在其目的地的任何訊息，即使它們是持續訊息也一樣。

如果不要遺失訊息很重要，您必須指定應用程式的存活時間值，該值足以確保訊息在中斷期間不會遺失。

訊息的持續性是由發佈和訂閱應用程式以及 IBM MQ 主題物件的配置所控制。

如果 AMQP 訂閱者使用 QOS 0 (最多一次) 並建立不可延續訂閱，則不論下列文字中說明的其他選項為何， AMQP 通道一律會將非持續訊息放入訂閱者佇列。

請注意，如果佇列管理程式已停止，則訂閱及訊息都會遺失。

如果 AMQP 發佈者將 AMQP durable 標頭設為 true，則 AMQP 通道會將持續訊息放入訂閱者佇列。

如果佇列管理程式因任何原因而停止，當佇列管理程式重新啟動時，訊息仍可供訂閱者使用。

如果未設定 durable 標頭， AMQP 通道會根據相關 IBM MQ 主題物件的 DEFPSIST 屬性，選擇已發佈訊息的持續性。

依預設，這是 SYSTEM.BASE.TOPIC，使用 DEFPSIST 屬性 NO (非持續性)。

注意: 較新版本的 MQ Light 用戶端不支援設定 AMQP 可延續標頭。