|
| |
| Sun Java System Message Queue 3 2005Q1 技術概述 | |
第3章
可靠訊息傳送本章說明 Message Queue 服務如何提供可靠訊息傳送。它透過系統追蹤訊息的路徑，描述用來路由和傳送訊息至相應用戶的不同機制，並保證傳送訊息。
本章包含下列主題：
本章內容同時適合開發者和管理員閱讀，並對第 2 章「Message Queue 簡介」的資訊加以補充。
訊息在系統中的行程利用 Message Queue 訊息服務傳送訊息，從訊息生產者到訊息用戶的過程說明於圖 3-1。以下小節提供更多傳送過程中每個階段的詳細描述。
圖 3-1 訊息傳送步驟
一個永久性、可靠且已傳送之訊息的訊息傳送步驟如下：
訊息生產
1. 用戶端執行階段透過連線從訊息生產者傳送訊息至訊息伺服器。
訊息處理和訊息路由
2. 訊息伺服器從連線讀入訊息並將之放入相應的目標。
3. 訊息伺服器將 (永久性) 訊息放入資料儲存。
4. 訊息伺服器向訊息生產者的用戶端執行階段確認訊息接收。
5. 訊息伺服器會判斷訊息的路由。
6. 訊息伺服器由其目標將訊息寫至相應的連線。
訊息使用
7. 訊息用戶的用戶端執行階段從連線傳送訊息至訊息用戶。
8. 訊息用戶的用戶端執行階段確認訊息至訊息伺服器的使用。
訊息使用終了
9. 訊息伺服器處理用戶端確認，同時從目標和資料儲存刪除 (永久性) 訊息。
10. 訊息伺服器向用戶的用戶端執行階段確定用戶端確認已處理，且訊息無法再被傳送。
在系統處理訊息的這些傳送步驟中的作法分為兩類：
訊息傳送處理利用 Message Queue 服務處理訊息，在訊息從生產者至用戶的傳送方法中，有幾個處理階段，如圖 3-1 中步驟的說明。
階段如下：
這些階段在下面的小節中會有說明。
訊息生產
在訊息生產中，訊息由用戶端建立，且用戶端執行階段透過連線傳送至代理程式上的目標。
如果訊息的傳送模式被設定成永久性 (保證傳送，一次並僅使用一次，即使代理程式故障)，代理程式，依預設，會將一個控制訊息 (一個代理程式確認) 傳送回用戶端執行階段。代理程式確認指出代理程式已傳送訊息至目標，且將訊息存放在代理程式的資料儲存。用戶端執行緒會進行封鎖直到它收到代理程式確認。
如果訊息的傳送模式被設成非永久性，則代理程式，依預設，不會將代理程式確認傳送回用戶端執行階段，且用戶端執行緒也不會封鎖。然而，如果要知道代理程式是否收到非永久訊息很重要，您可以啟用代理程式確認。事實上，在達到目標的記憶體限制時，必須啟用代理程式確認來減緩訊息生產 (請參閱目標訊息限制)。
訊息處理和訊息路由
當代理程式收到一個進來的 JMS 有效負載訊息時，它會將訊息放在指定目標並隨後將訊息路由至對應的一個或多個用戶。
一般來說，所有訊息會保留在實體目標 (記憶體) 中，直至它們已被傳送或過期。如果代理程式出現故障，則這些訊息會遺失。如果是永久性訊息，代理程式會將它存放在資料庫或檔案系統中並在故障之後回復訊息。
訊息的處理取決於它的目標類型 - 佇列或主題 - 如以下小節中的說明。它也取決於當管理員建立實體目標時為目標設定的目標特性。
佇列目標
佇列目標用於點對點訊息傳送，其中訊息僅用來傳送給一位用戶並供其使用。
將佇列中的任何一個訊息僅傳送給單一用戶時，Message Queue 允許多個用戶註冊佇列。代理程式可隨後將訊息分散到不同的註冊用戶，以平衡負載。
基本的路由機制
當訊息從產生者到達時，它們會形成佇列。當訊息到達佇列前面時會被路由至註冊佇列的單一用戶。訊息到達佇列前面的順序，取決於它到達的順序及優先順序。
如果選擇器特性值被設到訊息中，代理程式會將它和註冊用戶指定的任何選擇器值作比較，並在路由訊息至用戶前確保符合選擇器值。
佇列傳送至多個用戶
實作到多個用戶的佇列傳送會根據數個佇列目標特性來使用一個可配置的負載平衡方法：
如果用戶數目超過這兩個特性的數目總和，將會拒絕新的用戶。(Message Queue 平台版在每個佇列最多支援 3 個用戶 - 兩個使用中和一個備份而 Message Queue 企業版則支援無限個用戶。)
負載平衡機制會考慮不同用戶的訊息使用率。在可配置大小的批次中，佇列目標中的訊息會路由到可用的新使用中用戶，以便用戶註冊佇列 (佇列目標的用戶流量限制特性)。一旦傳送這些訊息，其他到達佇列的訊息會在用戶為可用狀態時在批次中路由到用戶。當用戶使用先前傳送給他的訊息的可配置百分比後，用戶成為啟用狀態。換言之，每個用戶的派送比例根據用戶目前的容量和訊息處理比例而異。
如果一個使用中的用戶失敗，第一位備份用戶就會變成使用中，並取代失敗用戶的工作。因為這些機制，如果佇列目標有一個以上的使用中用戶時，則無法保證訊息使用的順序。
訊息產生率低時，代理程式可能會不規則地派送訊息給使用中用戶。如果使用中用戶多於所需數目時，部分的用戶可能會收不到任何訊息。
在代理程式叢集環境中，您可以將傳送到多個用戶的功能，設定為先傳送給本地用戶。您可使用佇列目標特性來指定只有在產生者的本機代理程式 (即產生者向其傳送訊息的代理程式) 沒有用戶時，才會將訊息傳送給遠端用戶。在路由到遠端用戶 (透過用戶的本機代理程式) 可能會降低流量速率的情況下，此設定可讓您增加路由到遠端用戶的效能。
主題目標
主題目標用於出版/訂閱訊息傳送，其中訊息表示用來傳送至已在目標中註冊其興趣的所有用戶。
基本的路由機制
當一個訊息從產生者到達時，它會被路由至訂閱此主題的所有用戶。如果用戶已註冊此主題的長期訂閱，則他們不需在訊息傳送至此主題時成為使用中用戶：代理程式會儲存訊息直至用戶再次成為使用中用戶，然後傳送訊息。
如果選擇器特性值被設到訊息中，代理程式會將它和註冊用戶指定的任何選擇器值作比較，並在路由訊息至用戶前確保符合選擇器值。
長期訂閱和用戶端識別碼
一個用戶只能有一個主題的長期訂閱。當使用者開啟和關閉至訊息伺服器的連線時，使用者的識別必須維持不變。 用戶端識別碼就是用來確保每個長期訂閱都只對應到一個使用者。
用戶端識別碼將用戶端至訊息伺服器的連線與代表用戶端的訊息伺服器所維護的狀態資訊相關聯。依定義，用戶端識別碼是唯一的。
若要建立長期訂閱，用戶端識別碼必須由用戶端使用 JMS API 方式呼叫來透過程式設定，或在用戶端使用的連線工廠物件中進行管理級別的配置。
訊息使用
一旦訊息被路由，它們會被分別傳送至它們的用戶。當用戶收到一個有效負載訊息後，此使用用戶端執行階段會傳送回它已接收到並已處理此訊息的確認給代理程式。代理程式在從它的目標刪除訊息之前，會等待這項用戶端確認。用戶端確認可以套用到個別訊息、群組訊息或作業事件。
用戶端確認
根據 JMS 規格，用戶端在建立階段作業時可指定三個基本確認模式中的一個。選擇何種模式取決於您想要的訊息傳送可靠性：
Message Queue 利用額外的 NO_ACKNOWLDEGE 模式，擴充用戶端確認模式的設定。基本和擴充模式如下面小節中的說明。
AUTO_ACKNOWLEDGE 模式
在 AUTO_ACKNOWLEDGE 模式中，階段作業自動確認用戶端使用的每個訊息。此外，階段作業執行緒會封鎖，以等待代理程式確定已處理每個使用訊息用戶端的確認。這個確定就稱為代理程式確認。
CLIENT_ACKNOWLEDGE 模式
CLIENT_ACKNOWLEDGE 模式給予用戶端最大的控制權。在這個模式中，用戶端會在使用一個或多個訊息之後明確確認。用戶端呼叫訊息物件的 acknowledge() 方法，致使階段作業確認自上次呼叫該方法以來它所使用的所有訊息。(這可能包含在階段作業中由不同訊息偵聽程式非同步使用的訊息，並和它們的使用順序無關。)
此外，階段作業執行緒會封鎖，等待返回的代理程式確認訊息使用的批次，以確認代理程式已處理用戶端確認。
因為用戶端確認和代理程式確認通常會分為幾個批次 (而不是一個個傳送)，CLIENT_ACKNOWLEDGE 模式和 AUTO_ACKNOWLEDGE 模式相比，前者通常會保存連線頻寬並降低代理程式確認的耗用時間。當然，如果在這個模式，因為用戶端會確認每個訊息，所以將不會發生分批傳送，而確認就會一個個傳送。
備註
Message Queue 也提供一個指定模式讓您可以在 CLIENT_ACKNOWLEDGE 模式中使用，透過它您可以只確認呼叫方式上的個別訊息，而不使用標準運作方式。這可以利用在「Message Queue Developer's Guide for Java Clients」中說明的程式設計技術來達成。
DUPS_OK_ACKNOWLEDGE 模式
在 DUPS_OK_ACKNOWLEDGE 模式中，階段作業會在使用十個訊息後確認。這個值目前不能配置。和 AUTO_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE 模式不同，階段作業執行緒不會封鎖等待代理程式確認，因為在 DUPS_OK_ACKNOWLEDGE 模式中不需要代理程式確認。
這表示不能保證訊息已被傳送且僅使用一次。一般來說，訊息將不會常常被重新傳送；它們僅會在故障發生時重新傳送，因為代理程式沒有收到用戶端確認訊息已送達。如果不在意重複傳送的話，用戶端應使用 DUPS_OK_ACKNOWLEDGE 模式。
因為用戶端確認是分批傳送，且用戶端執行緒不產生封鎖，訊息流量通常會較其他模式高許多。
NO_ACKNOWLEDGE 模式
在 NO_ACKNOWLEDGE 模式中，代理程式執行代表用戶端的用戶端確認，因此不保證訊息已被使用用戶端成功處理。
當訊息流量很重要而不重視可靠傳送時可使用此模式。這是可能會發生的狀況，例如在一段短時間間隔內訊息被定期傳送時，訊息負載會較高，而訊息的遺失沒有太大關係。
這個模式擴充了 JMS 規格且僅能由不需要與其他 JMS 提供者工作的用戶端使用。
作業事件
以上描述的用戶端與代理程式確認過程，還適用於群組至作業事件中的 JMS 訊息傳送。在這些情況下，用戶端與代理程式確認可對作業事件級別作業，包括在作業事件中所有涉及的訊息。確定作業事件時，代理程式確認會被自動傳送。
代理程式追蹤作業事件，並可在發生故障時對作業事件進行確定或回復。本作業事件管理還支援本機作業事件，此為較大型分散式作業事件 (請參閱分散式作業事件) 的一部分。代理程式會追蹤這些作業事件的狀態，直至它們被確定。代理程式啟動時，它會檢查所有未確定的作業事件，並依預設，會回復所有作業事件 (那些處於 PREPARED 狀態必須手動解決的作業事件除外)。
Message Queue 透過 XA 連線工廠實作對分散式作業事件的支援，這可讓您建立 XA 連線，而 XA 連線又可讓您建立 XA 階段作業。此外，對分散式作業事件的支援還要求協力廠商 Java Transaction Service (JTS) 或與 J2EE 相容的 Application Server (提供 JTS)。
訊息使用終了
代理程式在成功傳送訊息後從目標記憶體刪除訊息。然而，有時訊息還是可能在還未成功傳送前被捨棄。下面的小節中說明在哪些情況下訊息會被捨棄。
訊息的正常刪除
在正常情況下，代理程式在訊息成功傳送並收到用戶端確認後才從目標記憶體刪除訊息。
當代理程式傳送一個訊息給用戶時，它會標示該訊息為已傳送，但不確知訊息是否已被接受並且被使用。因此，代理程式會在將訊息從實體目標和永久性儲存刪除前等待用戶端確認。
如果訊息是送至一個主題，代理程式不會刪除該訊息直到從每個接收訊息的訊息用戶處收到用戶端確認。如果用戶為主題的長期訂閱，則代理程式會將每個訊息保留在目標中，並當每個長期用戶成為使用中用戶時傳送此訊息。代理程式接收用戶端確認時會記錄這些確認，並僅在已接收所有確認後才刪除訊息 (除非訊息在此之前已過期)。根據用戶端的確認模式，代理程式可能透過傳送一個代理程式確認回傳給用戶端來確認用戶端確認的接收。
如果代理程式或連線故障，代理程式可能收不到用戶端確認而重新傳送所有之前已傳送但未確認的訊息，並為它們標示一個 Redelivered 旗標。例如，如果佇列用戶在確認訊息的接收之前離線，且其他用戶 (或甚至同一用戶) 在之後註冊該佇列，代理程式將重新傳送該未確認訊息給新用戶，並為該訊息標示一個 Redelivered 旗標。訊息重新傳送的用戶端應用程式在此種情況下應該檢查訊息的旗標。
訊息的不正常刪除
當訊息無法被傳送時，取決於造成訊息無法傳送的情況，會被捨棄或放置在停用訊息佇列上。
一個訊息在下列情況下可能在尚未被成功傳送和使用前遭到代理程式捨棄：
然而，在這些情況下，訊息將被視為停用和捨棄或放置在停用訊息佇列上，取決於您配置的運作方式：
您可選擇保留這些訊息並將它們放置在停用訊息佇列中。在放置訊息至停用訊息佇列時，代理程式寫入指定的 Message Queue 特性值至訊息，指出放入訊息的時間和原因。
您可在之後從停用訊息佇列中擷取訊息供診斷目的使用。請參閱停用的訊息佇列，以獲得更多資訊。
效能問題訊息傳送的可靠性越高，需要的耗用時間和頻寬就越多。因此，可靠性與效能之間的平衡是設計時要考慮的重點。您可以透過選擇生產和使用非永久性訊息來最大化效能。另一方面，您也可以透過生產和使用永久性訊息並使用作業事件階段作業來最大化可靠性。在這兩種極端之間有許多選擇，這取決於每個應用程式的需要。
例如，訊息處理速率就受到許多因素的影響，包括訊息應用程式的設計、訊息伺服器的配置和用戶端執行階段的配置。雖然這些因素相當不同，它們的互動卻能讓最大效能的工作複雜化。
本節簡要複習一些在可靠性與效能之間取得平衡時要計算的因素。
傳送模式 傳送模式指定訊息為最多只傳送一次 (非永久性) 或一次且僅有一次 (永久性)。永久性訊息的管理需要使用代理程式確認連線上的訊息流量和使用用戶端確認模式來封鎖，以等待收到代理程式的確認。若要增加流量，您可設定用戶端執行階段以抑制代理程式確認，但這麼做會取消保證永久性訊息已被傳送一次且僅有一次。
用戶端確認模式 四個用戶端確認模式中的每一個都需要不同的處理級別和頻寬耗用時間。AUTO_ACKNOWLEDGE 模式使用最大耗用時間但根據訊息基礎保證可靠度，CLIENT_ACKNOWLEDGE 模式分批傳送確認，也因此只需要較少的頻寬耗用時間， 而 DUPS_OK_ACKNOWLEDGE 模式則使用最少耗用時間，但允許訊息的重複傳送。NO_ACKNOWLEDGE 模式有最佳的效能但可能要付出遺失訊息的代價。
用戶端應用程式設計 階段作業中形成佇列的訊息數目為使用階段作業之用戶數目及用於每個用戶之訊息負載的函數。如果用戶端在產生或使用訊息中速度緩慢，通常您可以藉由重新設定應用程式，以分散較大階段作業數目上的訊息產生者和用戶，或者分散較大連線數目上的階段作業，並因此改善效能。影響效能的設計問題在「Message Queue Developer's Guide for Java Clients」和「Message Queue Developer's Guide for C Clients」中說明。
訊息流量計數 連線頻寬的控制訊息和有效負載訊息間的競爭，可以透過用戶端執行階段來管理。適當配置用戶端執行階段能有助於加速代理程式確認的傳送、釋放封鎖階段作業執行緒並加速訊息的使用。請參閱「Message Queue 管理指南」，以取得更多資訊。
訊息流量限制 訊息使用速度可能在達到用戶端執行階段資源限制時變慢。藉由限制保留在用戶端執行階段中等待被一個或多個用戶使用的訊息數目，可以避免這些資源限制。請參閱「Message Queue 管理指南」，以取得更多資訊。
