上一章 目錄 索引 下一章 |
Sun Java System Message Queue 3.5 SP1 管理指南

> ## 第 2 章
> Message Queue 訊息傳送系統

> 本章描述 Sun Java™ System Message Queue 訊息傳送系統，並介紹此系統的主要部分如何共同工作以提供可靠的訊息發送，這些詳細說明的主要部分如圖 2-1 中所示。

> 圖 2-1 Message Queue 系統架構

> 圖 2-1 中所示的 Message Queue 訊息傳送系統的主要部分如下：

> - Message Queue 訊息伺服器
> - Message Queue 用戶端運行時間
> - Message Queue受管理物件
> - Message Queue 管理

> 前三個部分將在以下各節中詳細說明。最後一個部分將在第 3 章「Message Queue 管理工作和工具」中介紹。

> ##

> Message Queue 訊息伺服器

> 本節描述圖 2-1 中所示的 Message Queue 訊息伺服器的不同部分。這些部分包括：

> 代理程式 Message Queue 代理程式為 Message Queue 訊息傳送系統提供發送服務。訊息發送依賴一些支援元件，這些元件可處理連接服務、訊息路由與發送、持續性、安全性以及記錄 (請參閱「代理程式」 以獲得更多資訊)。訊息伺服器可使用一個或多個代理程式實例 (請參閱「多重代理程式叢集 (企業版)」)。

> 實體目標 訊息發送過程分為兩個階段 - 從生產型用戶端發送至由代理程式維護的實體目標，然後從目標發送至一個或多個使用用戶端。實體目標表示在代理程式的實體記憶體和/或永久性儲存體中的位置 (請參閱「實體目標」 以獲得更多資訊)。

> ### 代理程式

> Message Queue 訊息傳送系統中的訊息發送 - 從生產型用戶端至目標，然後從目標至一個或多個使用用戶端 - 由代理程式 (或以串聯方式工作的代理程式實例叢集) 執行。若要執行訊息發送，代理程式必須配置與用戶端通訊的通道、執行認證與授權、適當路由訊息、確保可靠發送，並為監視系統效能提供資料。

> 若要執行這套複雜的功能，代理程式將使用一些不同的內部元件，並且每個元件在發送過程中都有特定的作用。圖 2-2 中說明主代理程式元件，表 2-1 中則簡單描述這些元件。訊息路由器元件執行主要的訊息路由和發送服務，其他的訊息路由和發送服務則提供重要的支援服務給訊息路由器。

> 圖 2-2 代理程式服務元件

> 表 2-1 主代理程式服務元件和功能

> 元件 | 說明/功能
> --- | ---
> 訊息路由器 | 管理訊息的路由與發送：這些訊息包括 JMS 訊息以及 Message Queue 訊息傳送系統為支援 JMS 訊息發送而使用的控制訊息。
> 連接服務 | 管理代理程式與用戶端之間的實體連接，為進來和外送的訊息提供傳輸。
> 持續性管理程式 | 管理向永久性儲存體的資料寫入，以便系統故障不會導致發送 JMS 訊息的故障。
> 安全性管理程式 | 為請求連接至代理程式的使用者提供認證服務，為已認證的使用者提供授權服務 (存取控制)。
> 監視服務 | 產生可以寫入大量輸出通道的度量和診斷資訊，另外，管理員可以使用輸出通道來監視和管理代理程式。

> 根據載入條件、應用程式的複雜性等，您可以配置這些內部元件，以最佳化代理程式的效能。以下各節更全面地探究不同的元件所執行的功能，以及可配置為影響元件運作方式的特性。

> #### 連接服務

> Message Queue 代理程式支援與 Message Queue 應用程式用戶端和 Message Queue 管理用戶端的通訊 (請參閱「Message Queue 管理工具」)。每種服務均由其服務類型和協定類型指定。

> 服務類型 指定此服務提供 JMS 訊息發送 (NORMAL) 或提供 Message Queue 管理 (ADMIN) 服務

> 協定類型 指定支援此服務的基本傳輸協定層。

> 目前，Message Queue 代理程式可提供的連接服務如表 2-2 中所示：

> 表 2-2 代理程式支援的連接服務

> 服務名稱 | 服務類型 | 協定類型
> --- | --- | ---
> jms | NORMAL | tcp
> ssljms (企業版) | NORMAL | tls (基於 SSL 的安全性)
> httpjms (企業版) | NORMAL | http
> httpsjms (企業版) | NORMAL | https (基於 SSL 的安全性)
> admin | ADMIN | tcp
> ssladmin (企業版) | ADMIN | tls (基於 SSL 的安全性)

> 您可以將代理程式配置為執行這些連接服務的任何一種或全部。每種連接服務可用於特定的連接埠，此連接埠由代理程式的主機名稱和連接埠號指定。可以動態配置連接埠，或您可以指定連接服務為可用時的連接埠。

> 每種服務皆使用共用連接埠對映器登錄，但它們均有自己的執行緒儲存區管理程式，如圖 2-3 所示。

> 圖 2-3 連接服務支援

> ##### 連接埠對映器

> Message Queue 會提供一個連接埠對映器，以將連接埠對映到不同的連接服務。連接埠對映器本身常駐在標準的連接埠號 7676 上。當用戶端配置與代理程式的連接時，它會先聯絡連接埠對映器，以請求其所需的連接服務的連接埠號。

> 您也可以在配置這些連接服務時，為 jms、ssljms、admin 和 ssladmin 連接服務指定一個靜態連接埠號，但只有在特殊情況下才會這麼做 (例如透過防火牆建立連接時)，且通常不建議這麼做。使用附錄 C「HTTP/HTTPS 支援 (企業版)」的表 C-1 和表 C-3 中描述的特性，可分別配置 httpjms 和 httpsjms 服務。

> ##### 執行緒儲存區管理程式

> 每種連接服務均為多重執行緒，支援多重連接。這些連接所需的執行緒，在執行緒儲存區管理程式元件所管理的執行緒儲存區中維護。您可以配置此執行緒儲存區管理程式，以配置此執行緒儲存區中所維護的執行緒的最小數目和最大數目。由於連接需要執行緒，因此可將執行緒新增至執行緒儲存區。當超過最小數目時，系統將關閉執行緒 (因為這些執行緒將成為自由執行緒，直至達到最小數目的臨界值)，從而節省記憶體資源。您應將此數目變得足夠大，以便不必繼續建立新的執行緒。載入大量連接後，執行緒的數目會增加，直至達到執行緒儲存區的最大數目，然後連接必須等待，直至某執行緒變為可用。

> 執行緒儲存區中的執行緒可專屬於單一連接 (專屬模型)，或依需要指定給多重連接 (共用模型)。

> 專屬模型 每個到代理程式的連接均要求兩個專屬執行緒：一個專門負責處理連接進來的訊息，另一個則專門處理連接外送的訊息。這可將連接數目限制為執行緒儲存區中最大執行緒數目的一半，但它可提供高效能。

> 共用模型 (企業版) 傳送或接收訊息時，共用執行緒會負責處理連接。因為每個連接皆沒有要求專屬執行緒，所以此模型會增加一個連接服務 (和代理程式) 可支援的連接數目。但也會增加共用執行緒中效能耗用的時間。執行緒儲存區管理程式使用一套分散執行緒，可監視連接狀態並依需要將連接指定給執行緒。透過限制每個此類分散執行緒監視的連接數目，在此活動中效能耗用的時間可以縮到最短。

> ##### 安全性

> 每種連接服務可支援特定認證和授權 (存取控制) 功能 (請參閱「安全性管理程式」)。

> ##### 連接服務特性

> 表 2-3 中顯示與連接服務相關的可配置特性。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 表 2-3 連接服務特性

> 特性名稱 | 說明
> --- | ---
> imq.service.activelist | 要在啟動代理程式時變為作用中的連接服務的清單，這些連接服務依名稱列出並以逗號分隔。支援的服務為：jms、ssljms、httpjms、httpsjms、admin 和 ssladmin。 預設：jms 和 admin
> imq.ping.interval | 代理程式透過連接，連續嘗試偵測 Message Queue 用戶端執行時間的期間。 預設：120 秒
> imq.hostname | 如果有多台主機可用 (例如，如果一台電腦中有多張網路介面卡)，則指定所有連接服務所連結的主機 (主機或 IP 位址)。 預設：所有可用 IP 位址
> imq.portmapper.port | 指定代理程式的主要連接埠 - 連接埠對映器常駐的連接埠。如果您要在主機上執行多個代理程式實例，則必須為每個實例指定唯一的連接埠對映器連接埠。 預設： 7676
> imq.portmapper.hostname | 如果有多台主機可用 (例如，如果一台電腦中有多張網路介面卡)，則指定連接埠對映器所連結的主機 (主機或 IP 位址)。 預設：繼承 imq.hostname 的值
> imq.portmapper.backlog | 指定拒絕請求前，連接埠對映器可以處理運作請求的最大數目。 此特性可以配置請求數目，另外，這些請求可儲存在作業系統儲存區，等待連接埠對映器進行處理。 預設： 50
> imq.service_name. protocol_type1.port | 僅用於 jms、ssljms、admin 和 ssladmin 服務，為已命名的連接服務指定連接埠號。 預設：0 (連接埠由連接埠對映器動態配置) 若要配置 httpjms 和 httpsjms 連接服務，請參閱附錄 C「HTTP/HTTPS 支援 (企業版)」。
> imq.service_name. protocol_type1.hostname | 僅用於 jms、ssljms、admin 和 ssladmin 服務，如果有多台主機可用 (例如，如果一台電腦中有多張網路介面卡)，指定已命名的連接服務所連結的主機 (主機名稱或 IP 位址)。 預設：繼承 imq.hostname 的值
> imq.service_name. min_threads | 指定執行緒數目，一旦達到指定數目，執行緒便會在執行緒儲存區中維護，供已命名的連接服務使用。 預設：取決於連接服務 (請參閱表 5-1)。
> imq.service_name. max_threads | 指定執行緒數目，一旦超過指定數目，系統便不會將新的執行緒新增至執行緒儲存區，供已命名的連接服務使用。此數目必須大於零，並且其值必須大於 min_threads 的值。 預設：取決於連接服務 (請參閱表 5-1)。
> imq.service_name. threadpool_model | 指定執行緒是專屬於連接 (dedicated) 或依需要由連接共用 (shared)，以用於已命名的連接服務。共用模型 (執行緒儲存區管理) 會增加代理程式所支援的連接數目，但僅實施用於 jms 和 admin 連接服務。 預設：取決於連接服務 (請參閱表 5-1)。
> imq.shared. connectionMonitor_limit | 僅用於共用執行緒儲存區模型，指定可由分散執行緒監視的最大連接數目。(系統配置了足夠的分散執行緒以監視所有連接。) 此值越小，系統將作用中的連接指定給執行緒的速度就越快。值 -1 表示沒有限制。 預設：取決於作業系統 (請參閱表 5-1)。

> 1 protocol_type (協定類型) 在表 2-2中指定。

> #### 訊息路由器

> 一旦使用支援的連接服務在用戶端和代理程式之間建立了連接，則可進行訊息路由與發送。

> ##### 基本的發送機制

> 概括地講，代理程式所處理的訊息分為兩類：由產生者用戶端傳送且目標為使用者用戶端的有效載入 JMS 訊息，以及為了支援 JMS 訊息發送而向用戶端傳送及從其中發出的一些控制訊息。

> 如果進來的訊息為 JMS 訊息，則代理程式將基於此訊息的目標類型 (佇列或主題)，將其路由至使用者用戶端：

> - 如果目標為主題，則 JMS 訊息將立即路由至此主題的所有作用中用戶。如果用戶為非作用中的長期用戶，則訊息路由器將保留此訊息，直至此用戶成為作用中用戶，然後將此訊息發送至此用戶。
> - 如果目標為佇列，則 JMS 訊息將放置在相應的佇列中，然後在此訊息到達佇列前面時被發送至適當的使用者。訊息到達佇列前面的順序，取決於它們到達的順序及優先順序。

> 一旦訊息路由器將訊息發送至所有預定的使用者，它便會將此訊息從記憶體中清除，如果此訊息為永久性的 (請參閱「可靠的訊息傳送」)，它會將其從代理程式的永久性資料儲存區中移除。

> ##### 可靠發送：確認與異動

> 當為可靠發送 (請參閱「可靠的訊息傳送」) 新增需求時，剛才描述的發送機制會變得更加複雜。可靠發送包含兩個方面：確保向代理程式傳送及從其中發出的訊息發送成功，並確保實際發送訊息之前，代理程式不會遺失訊息或發送資訊。

> 為確保訊息成功遞送至代理程式及從其中成功發出，Message Queue 使用了一些名為確認的控制訊息。

> 例如，當產生者將 JMS 訊息 (收費載入訊息而不是控制訊息) 傳送至目標時，代理程式會傳送回控制訊息 (即代理程式確認)，表明它已接收到此 JMS 訊息。(依預設，僅當產生者指定 JMS 訊息為永久性時，Message Queue 才會執行此作業。)生產型用戶端使用代理程式確認，以確保發送至目標 (請參閱「訊息生產」)。

> 同樣，當代理程式將 JMS 訊息發送至使用者時，此使用用戶端會傳送回它已接收到並已處理此訊息的確認。建立階段作業物件時，用戶端會指定如何自動或頻繁地傳送這些確認，但原則是，如果訊息路由器沒有從它已向其遞送訊息的每個訊息使用者 (例如，從主題的多重用戶的每個用戶) 接收到確認，則它不會從記憶體中刪除 JMS 訊息。

> 如果用戶為主題的長期訂閱，則訊息路由器會將每個 JMS 訊息保留在目標中，並當每個長期用戶成為作用中使用者時發送此訊息。訊息路由器接收用戶端確認時會記錄這些確認，並僅在已接收所有確認後才刪除 JMS 訊息 (除非 JMS 訊息在此之前已過期)。

> 而且，透過將代理程式確認傳送回用戶端，訊息路由器確認用戶端確認的接收。使用用戶端使用代理程式確認，以確保代理程式不會多次發送同一 JMS 訊息 (請參閱「訊息使用」)。如果由於某種原因而使代理程式無法接收到用戶端確認，則可能發生上述情況。

> 如果代理程式沒有接收到用戶端確認並再次發送 JMS 訊息，則此訊息會標記有重新發送旗標。如果用戶端連接在代理程式接收到用戶端確認之前關閉，並隨後開啟新的連接，則此代理程式通常會重新發送 JMS 訊息。例如，如果佇列的訊息使用者在確認訊息之前離線，而且另一個使用者隨後註冊此佇列，則代理程式將未確認的訊息重新發送至此新的使用者。

> 以上描述的用戶端與代理程式確認過程，還適用於群組至異動中的 JMS 訊息發送。在這些情況下，用戶端與代理程式確認可對異動作業，亦可對傳送或接收的個別 JMS 訊息作業。確定異動時，代理程式確認會被自動傳送。

> 代理程式會追蹤異動，並可在發生故障時對異動進行確定或回轉。本異動管理還支援本機異動，此為較大型分散式異動 (請參閱「分散式異動」) 的一部分。代理程式會追蹤這些異動的狀態，直至它們被確定。代理程式啟動時，它會檢查所有未確定的異動，並依預設，會回轉所有異動 (那些處於 PREPARED 狀態的異動除外)。

> ##### 可靠發送：持續性

> 可靠發送的另一個方面是，確保實際發送訊息之前，代理程式不會遺失訊息或發送資訊。一般來說，訊息會保留在記憶體中，直至它們已被發送或過期。但是，如果代理程式出現故障，則這些訊息會遺失。

> 產生者用戶端可指定訊息為永久性的，在此情況下，訊息路由器會將此訊息傳送至將此訊息儲存在資料庫或檔案系統中的持續性管理程式 (請參閱「持續性管理程式」)，以便在代理程式出現故障時回復此訊息。

> ##### 管理記憶體資源和訊息流量

> 代理程式的效能和穩定性取決於可用的系統資源，以及如何有效利用記憶體之類的資源。要特別注意的是，訊息產生速度快於使用速度時，會使用到所有的記憶體資源，因而訊息路由器可能過度負載。若要預防發生此情形，訊息路由器會使用三個記憶體保護級別，以在資源不足時維持系統作業：

> 個別目標上的訊息限制 您可以配置實體目標上的屬性，以指定訊息數目和訊息使用的總記憶體 (請參閱表 6-10)。您也可以指定到達任何此類限制時，訊息路由器將產生的四個確認類型。四個限制行為：

> - 減緩訊息產生者速度
> - 拋出記憶體中最舊的訊息
> - 根據訊息存在時間，拋出記憶體中具最低優先權的訊息
> - 拒絕最新的訊息

> 系統範圍訊息限制 系統範圍訊息限制為第二道保護。您可以指定適用於系統上之所有目標的系統範圍限制：訊息總數目和所有訊息使用的記憶體 (請參閱表 2-4)。如果到達任何系統範圍訊息限制，訊息路由器會拒絕新的訊息。

> 系統記憶體執行緒 系統記憶體執行緒為第三道保護。您可以指定代理程式採取越來越重要的動作時可用的系統記憶體執行緒，以防止記憶體超過負載。此動作取決於記憶體資源的狀態：green (大量記憶體可用)、yellow (代理程式記憶體正在減少)、orange (代理程式記憶體不足) 以及 red (代理程式無記憶體)。在代理程式的記憶體狀態從 green 變為 yellow 和 orange ，然後變為 red 的過程中，代理程式會採取越來越重要的動作，動作類型如下所示：

> - 將訊息移出作用中記憶體並放入永久性儲存體 (請參閱「持續性管理程式」)；通常不會儲存的非永久性訊息，可能會被移出，如此系統即可回收記憶體。
> - 減低非永久性訊息的產生者，最終使訊息停止流入代理程式 (永久性訊息流量會自動受到代理程式確認訊息之要求的限制)。

> 上述兩種方法皆會降低效能。

> 如果到達系統記憶體執行緒，那表示您尚未適當地按目標配置訊息限制和系統範圍訊息限制。在某些情況下，您無法及時為執行緒擷取潛在的記憶體負載。因此，您不應依賴此功能來控制記憶體資源，而是應個別且整體地配置目標，以最佳化記憶體資源。

> ##### 訊息路由器特性

> 表 2-4 中詳細說明了管理記憶體資源的系統範圍限制和系統記憶體執行緒。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 表 2-4 訊息路由器特性

> 特性名稱 | 說明
> --- | ---
> imq.message.expiration. interval | 指定回收已過期訊息發生的頻率 (以秒為單位)。 預設： 60
> imq.system.max_count | 指定代理程式保留訊息的最大數目。其他訊息將被拒絕。值 -1 表示沒有限制。 預設： -1
> imq.system.max_size | 指定代理程式保留訊息的最大總容量 (以位元組、千位元組或百萬位元組為單位)。其他訊息將被拒絕。值 -1 表示沒有限制。 預設： -1
> imq.message.max_size | 指定訊息內文的最大允許容量 (以位元組、千位元組或百萬位元組為單位)。任何大於該配置的訊息將被拒絕。值 -1 表示沒有限制。 預設：70m (百萬位元組)
> imq.resource_state. threshold | 指定啟動每種記憶體狀態時的記憶體利用百分比。資源狀態的值可以為 green、yellow、orange 和 red。 預設：分別為 0、80、90 和 98
> imq.resource_state.count | 指定在啟動每個記憶體資源狀態時，批次中允許進來的訊息的最大數目。系統記憶體變得逐漸不足時，此限制會減低訊息產生者。 預設：分別為 5000、500、50 和 0
> imq.transaction. autorollback | 指定處於 PREPARED 狀態的分散式異動是否可在啟動代理程式時自動回轉 (true/false)。如果為 false，則您必須使用 imqcmd 手動確定或回轉異動 (請參閱「管理異動」)。 預設： false

> #### 持續性管理程式

> 如果要回復的代理程式出現故障，則此代理程式需要重新建立其訊息發送作業的狀態。此操作要求它將所有永久性訊息以及重要的路由與發送資訊儲存至資料倉庫。持續性管理程式元件管理此資訊的寫入和擷取。

> 若要回復發生故障的代理程式，不僅只要復原未發送的訊息。代理程式還必須可執行以下作業：

> - 重新建立目標
> - 復原每個主題的長期訂閱清單
> - 復原每個訊息的確認清單
> - 重新生產所有已確定異動的狀態

> 持續性管理程式管理所有此狀態資訊的儲存和擷取。

> 重新啟動代理程式時，它會重新建立目標和長期訂閱、回復永久性訊息、復原所有異動的狀態，並為未發送訊息重新建立其路由表格。然後，它可以繼續訊息發送。

> Message Queue 支援內建和外掛持續性模組 (請參閱圖 2-4)。內建持續性是基於檔案的資料倉庫。外掛持續性使用 Java 資料庫連接 (JDBC™) 介面，並需要 JDBC 相容的資料倉庫。內建持續性通常快於外掛持續性；但是某些使用者更喜歡使用了 JDBC 相容資料庫系統的容錯和管理功能。

> 圖 2-4 持續性管理程式支援

> ##### 內建持續性

> 預設 Message Queue 永久性儲存體解決方案為基於檔案的資料倉庫。這種方法使用個別檔案儲存永久性資料，如訊息、目標、長期訂閱以及異動。

> 基於檔案的資料倉庫儲存於以代理程式實例 (instanceName) 作為辨別依據的目錄中，且代理程式實例與資料倉庫相互關聯 (請參閱附錄 A「Message Queue 資料的位置」)：

> _/instances/instanceName/fs350/

> 建立基於檔案的資料倉庫，以便根據永久性訊息於目標的常駐位置，將永久性訊息儲存在目錄中。大部分訊息會儲存在由智慧型記錄所組成的單一檔案中。

> 若要減少因新增和移除訊息而產生的分段程序，您可以壓縮智慧型記錄檔案 (請參閱「壓縮目標」)。除此之外，內建的持續性管理程式會將大小超過可配置執行緒的訊息 (imq.persist.file.message.max_record_size)，儲存在其個別檔案中，而非儲存於智慧型記錄檔案。針對這些個別檔案，要維護檔案儲存區，以便檔案被重新使用。當不再需要一個訊息檔案時，不會將它刪除，而是將它新增到其目標目錄中可用檔案的儲存區，以便用來儲存新的訊息。

> 您可以在檔案儲存區中配置檔案的最大數目 (imq.persist.file.destination.message.filepool.limit)，並在檔案儲存區中，指定欲清除之可用檔案的百分比 (the imq.persist.file.message.
> filepool.cleanratio)，即截斷至零，而不是僅做標記以供重新使用 (未截斷)。已清除檔案的百分比越高，維護此檔案儲存區所需的磁碟空間就越少，但耗用時間就越多。您還可以指定是否要在關機時清除已標記檔案 (imq.persist.file.message.cleanup)。如果這些檔案被清除，則它們將佔用很少的磁碟空間，但關閉代理程式則需較長時間。

> 所有其他永久性資料 (目標、長期訂閱和異動) 皆儲存在其個別檔案中：一個檔案中的所有目標、其他檔案中的所有長期訂閱等等。

> 若要最大化可靠性，您可以指定 (imq.persist.file.sync.enabled) 持續性作業同步化包含實體儲存裝置的內部記憶體狀態同步。這可以消除因系統當機而產生的資料遺失，但會影響效能。

> 因為資料倉庫可以包含敏感或專用性質的訊息，所以建議您保護 ...instances/instanceName/fs350/ 目錄，以防未經授權的存取。如需說明，請參閱「保護永久性資料」。

> ##### 外掛持續性

> 您可以配置代理程式，以透過 JDBC 驅動程式存取任何可存取的資料倉庫。這包含配置一些與 JDBC 相關的代理程式配置特性，以及使用資料庫管理員公用程式 (imqdbmgr) 來建立具有適當綱目的資料倉庫。附錄 B「設定外掛持續性」中詳細介紹了這些程序和相關的配置特性

> ##### 持續性管理程式特性

> 表 2-5 中詳細介紹了與持續性相關的配置特性。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 除了這些特性中的第一個屬性，所有表 2-5 中的屬性皆僅附屬內建持續性。表 B-1 中說明了附屬插入式持續性的特性。

> 表 2-5 持續性管理程式特性

> 特性名稱 | 說明
> --- | ---
> imq.persist.store | 指定代理程式使用內建、基於檔案 (file) 的持續性，或使用外掛 JDBC 相容 (jdbc) 的持續性。 預設：file
> imq.persist.file.sync. enabled | 指定持續性作業是否與實體儲存裝置以記憶體狀態同步化。如果為 true，則會結束由系統當機引起的資料遺失，但會降低持續性作業的效能。 預設：false
> imq.persist.file.message. max_record_size | 針對內建且基於檔案的持續性，請指定訊息新增到訊息儲存檔案的最大容量，而非儲存到個別檔案。 預設：1m (百萬位元組)
> imq.persist.file. destination.message. filepool.limit | 針對內建且基於檔案的持續性，指定目標檔案儲存區中，可供重新使用之可用檔案的最大數目。此數目越大，代理程式處理永久性資料的速度就越快。超過此數目的可用檔案將被刪除。代理程式將依需要建立與刪除超過此限制的其他檔案。 預設： 100
> imq.persist.file.message. filepool.cleanratio | 針對內建且基於檔案的持續性，指定目標檔案儲存區中被維護處於清除狀態之可用檔案的百分比 (截斷至零)。此值越高，則在作業期間清除檔案所需的耗用時間就越多，但檔案儲存區所需的磁碟空間就越少。 預設： 0
> imq.persist.file.message. cleanup | 針對內建且基於檔案的持續性，請指定代理程式關閉時，是否會清除目標檔案儲存區中的可用檔案。值 false 會加速代理程式的關閉速度，但檔案倉庫需要更多的磁碟空間。 預設：false

> #### 安全性管理程式

> Message Queue 提供認證與授權 (存取控制) 功能，還支援加密功能。

> 認證與授權功能因使用者儲存庫而異 (請參閱圖 2-5) ：包含有關訊息傳送系統使用者的資訊 (如使用者名稱、密碼和群組成員身份) 的檔案、目錄或資料庫。當請求與代理程式連接時，這些名稱和密碼用於認證使用者。使用者名稱和群組成員身份，連同存取控制檔案一起用於授權作業 (如針對目標生產或使用訊息)。

> Message Queue 管理員可寫入 Message Queue 所提供的使用者儲存庫 (請參閱「使用文字檔案使用者儲存庫」)，或將預先存在的 LDAP 使用者儲存庫插入安全性管理程式元件中 (請參閱「將 LDAP 伺服器用於使用者儲存庫」)。文字檔案使用者儲存庫易於使用，但其安全性易受侵害，因此應僅將其用於評估與開發，而 LDAP 使用者儲存庫很安全，因此最適合用於生產。

> ##### 認證

> Message Queue 安全性支援基於密碼的認證。當用戶端請求連接至代理程式時，它必須提交使用者名稱和密碼。安全性管理程式將此用戶端提交的名稱和密碼與儲存在使用者儲存庫中的名稱和密碼進行比較。將此密碼從用戶端傳送至代理程式時，系統會使用基本 64 編碼或訊息摘要 (MD5) 對密碼進行編碼。如需更加安全的傳送，請參閱「加密 (企業版)」。您可以分別配置每種連接服務所使用的編碼類型，或在代理程式範圍基礎上配置編碼。

> ##### 授權

> 一旦認證用戶端應用程式的使用者，此使用者便可被授權執行各種與 Message Queue 相關的作業。安全性管理程式支援基於使用者和基於群組的存取控制：根據使用者儲存庫中的使用者名稱或指定給此使用者的群組，此使用者可擁有執行某些 Message Queue 作業的許可權。您可在存取控制特性檔案 (請參閱圖 2-5) 中指定這些存取控制。

> 當使用者嘗試執行作業時，安全性管理程式會檢查使用者名稱和群組成員身份 (從使用者儲存庫)，是否與為存取此作業指定的那些名稱和成員身份 (在存取控制特性檔案中) 相符。存取控制特性檔案可指定以下作業的許可權：

> - 建立與代理程式的連接
> - 存取目標：為任何給定目標或所有目標建立使用者、產生者或佇列瀏覽器
> - 自動建立目標

> 圖 2-5 安全性管理程式支援

> 預設存取控制特性檔案僅明確參考一個群組：admin (請參閱「群組」)。admin 群組中的使用者擁有管理服務連接許可權。管理服務可讓使用者執行管理功能，如建立目標以及監視與控制代理程式。依預設，您定義的任何其他群組中的使用者均無法取得管理服務連接。

> 作為 Message Queue 管理員，您可以定義群組，並將使用者與使用者儲存庫中的那些群組相關聯 (儘管群組在文字檔案使用者儲存庫中不能完全得到支援)。然後，透過編輯存取控制特性檔案，您可以指定使用者和群組對目標的存取權，以用於生產和使用訊息，或在佇列目標中瀏覽訊息。您可以使個別目標或所有目標僅可由特定使用者或群組進行存取。

> 此外，如果代理程式已配置為允許自動建立目標 (請參閱「自動建立的 (對應管理員建立的) 目標」)，則您可以透過編輯存取控制特性檔案來控制代理程式可為何人自動建立目標。

> ##### 加密 (企業版)

> 若要加密在用戶端與代理程式之間傳送的訊息，您需要使用基於安全套接層 (SSL) 標準的連接服務。透過在已啟用 SSL 的代理程式與已啟用 SSL 的用戶端之間建立已加密連接，SSL 可提供連接級別的安全性。

> 若要使用 Message Queue 基於 SSL 的連接服務，您將使用鍵值工具公用程式 (imqkeytool) 產生私密密鑰/公開密鑰對。此公用程式將公開密鑰內嵌在自身簽名的憑證中，並放置在 Message Queue 密鑰儲存區中。Message Queue 密鑰儲存區自身具有密碼保護；若要對其解除鎖定，您必須在啟動時提供密鑰儲存區密碼。請參閱「加密：使用基於 SSL 的服務 (企業版)」。

> 一旦密鑰儲存區解除鎖定，則代理程式可將憑證傳送至請求連接的任何用戶端。然後，用戶端使用此憑證配置與代理程式的已加密連接。

> 表 2-6 中顯示用於認證、授權、加密以及其他安全通訊的可配置特性。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 表 2-6 安全性管理程式特性

> 特性名稱 | 說明
> --- | ---
> imq.authentication.type | 指定密碼應以基本 64 程式碼 (basic) 傳送，或作為 MD5 摘要 (digest) 傳送。為代理程式支援的所有連接服務配置編碼。 預設：digest
> imq.service_name. authentication.type | 指定密碼應以基本 64 程式碼 (basic) 傳送，或作為 MD5 摘要 (digest) 傳送。為已命名的連接服務配置編碼，並置換任何代理程式範圍的配置。 預設：繼承 imq.authentication.type 的值
> imq.authentication. basic.user_repository | (用於基本 64 程式碼) 指定用於認證的使用者儲存庫的類型，即基於檔案 (file) 或 LDAP (ldap)。如需其他 LDAP 特性，請參閱表 8-5。 預設：file
> imq.authentication. client.response.timeout | 指定系統等待用戶端確認來自代理程式的認證請求的時間 (以秒為單位)。 預設：180 (秒)
> imq.accesscontrol. enabled | 為代理程式支援的所有連接服務配置存取控制 (true/false)。表示系統是否將檢查已認證的使用者擁有使用連接服務的許可權，或擁有執行與特定目標相關的特定 Message Queue 作業的許可權 (如存取控制特性檔案中所指定)。 預設： true
> imq.service_name. accesscontrol.enabled | 為已命名的連接服務配置存取控制 (true/false)，並置換代理程式範圍的配置。表示系統是否將檢查已認證的使用者擁有使用已命名連接服務的許可權，或擁有執行與特定目標相關的特定 Message Queue 作業的許可權 (如存取控制特性檔案中所指定)。 預設：繼承imq.accesscontrol.enabled 的值
> imq.accesscontrol.file. filename | 為代理程式實例支援的所有連接服務，指定存取控制特性檔案的名稱。檔案名稱可指出到存取控制目錄的相關檔案路徑 (請參閱附錄 A「Message Queue 資料的位置」)。 預設： accesscontrol.properties
> imq.service_name. accesscontrol.file. filename | 為代理程式實例的已命名連接服務，指定存取控制特性檔案的名稱。檔案名稱可指出到存取控制目錄的相關檔案路徑 (請參閱附錄 A「Message Queue 資料的位置」)。 預設： 繼承imq.accesscontrol.file.filename的值。
> imq.passfile.enabled | 指定是否已在密碼檔案中指定用於安全通訊的使用者密碼 (用於 SSL、LDAP、JDBC™) (true/false)。 預設：false
> imq.passfile.dirpath | 指定包含密碼檔案之目錄的路徑 (因作業系統而異)。 預設：請參閱附錄 A「Message Queue 資料的位置」
> imq.passfile.name | 指定密碼檔案的名稱。 預設：passfile
> imq.keystore.property_name | 用於基於 SSL 的服務：指定與 SSL 密鑰儲存相關的安全性特性。請參閱表 8-8。

> #### 監視服務

> 代理程式包括一些用於監視和診斷其作業的元件。這些元件如下：

> - 產生資料的元件 (記錄事件與度量產生器的代理程式程式碼)
> - 記錄程式元件 (請參閱「記錄程式」)，可透過一些輸出通道寫出資訊
> - 訊息產生器，可將包含度量資訊的 JMS 訊息傳送到 JMS 監視用戶端使用的主題目標。

> 圖 2-6 中說明了一般機制。

> 圖 2-6 監視服務支援

> ##### 度量產生器

> 度量產生器提供代理程式活動的相關資訊，例如流入和流出代理程式的訊息流量、代理程式記憶體中的訊息數目和使用的記憶體、開啟連接的數目，以及使用的執行緒數目。

> 您可以開啟或關閉度量資料的產生，並指定產生度量報告的頻率。

> ##### 記錄程式

> Message Queue 記錄程式會取得代理程式程式碼產生的資訊和度量產生器，並將資訊寫入一些輸出通道：標準輸出 (主控台)、日誌檔及 Solaris™ 平台上的 syslog (系統日誌) 常駐程式。

> 您可以指定記錄程式收集的資訊類型，以及寫入每個輸出通道的類型。

> 例如您可以指定記錄程式級別，即記錄程式收集的資訊類型，範圍從最嚴重且最重要的資訊 (錯誤) 到不太重要的資訊 (度量資料)。表 2-7 中以重要性的降序方式顯示了資訊的種類：

> 表 2-7 記錄種類

> 種類 | 說明
> --- | ---
> ERROR (錯誤) | 表示可導致系統故障問題的訊息。
> WARNING (警告) | 應加以注意但不會導致系統故障的警示。
> INFO (資訊) | 度量和其他資訊性訊息的報告。

> 若要配置記錄程式級別，您可指定其中一個種類。記錄程式將寫出指定種類和所有更高級種類的資料。例如，如果您指定 WARNING 級別的記錄，則記錄程式將寫出警告資訊和錯誤資訊。

> 對於每個輸出通道，您均可以指定為記錄程式配置的哪些種類將寫入至此通道。例如，如果記錄程式級別配置為 INFO，則可以指定您僅將錯誤和警告寫入至主控台，以及僅將資訊 (度量資料) 寫入至日誌檔。(如需有關配置和使用 Solaris syslog 的資訊，請參閱 syslog(1M)、syslog.conf(4) 和 syslog(3C) 線上援助頁。)

> 在日誌檔中，您還可以指定何時關閉日誌檔並將輸出自動重建至新檔案。一旦日誌檔達到指定容量或存在時間，系統將儲存此日誌檔並建立新的日誌檔。日誌檔會被寫入以代理程式實例名稱 (instanceName) 作為辨別依據的目錄中，且代理程式實例與日誌檔相互關聯 (請參閱附錄 A「Message Queue 資料的位置」)：

> .../instances/instanceName/log/

> 當建立新的自動重建日誌檔時，將會保留 9 個最新日誌檔的歸檔檔案。

> 如需配置記錄程式的相關資訊，請參閱表 2-9和「變更記錄程式配置」。

> ##### 度量資訊產生者 (企業版)

> 訊息產生者元件會在固定時間間隔，從度量產生器元件收到資訊，並將資訊寫入訊息，接著根據訊息中包含的度量資訊類型，將訊息傳送到一些度量主題目標，

> 總共有 5 個度量主題目標。表 2-8中顯示了這些目標的名稱，和發送到每個目標的度量訊息類型。

> 表 2-8 度量主題目標

> 主題目標名稱 | 度量訊息的類型
> --- | ---
> mq.metrics.broker | 代理程式度量
> mq.metrics.jvm | Java 虛擬機器度量
> mq.metrics.destination_list | 目標及其類型的清單
> mq.metrics.destination.queue. monitoredDestinationName | 用於指定名稱之佇列的目標度量
> mq.metrics.destination.topic. monitoredDestinationName | 用於指定名稱之主題的目標度量

> 指定至這些度量主題目標的 Message Queue 用戶端，會使用目標中的訊息並處理訊息中包含的度量資訊。例如，用戶端可以指定到 mq.metrics.broker 目標，以接收和處理像是代理程式中訊息總數目的這類資訊。

> 度量訊息產生者為可建立訊息 (MapMessage 類型，包含與度量資料對應的名稱值對) 的內部 Message Queue 用戶端。只有在有一個或多個對應度量主題目標的用戶時，才會產生這些訊息。

> 度量訊息產生者產生的訊息類型為 MapMessage；它們是根據訊息包含的度量類型，由一些名稱/值對而組成。每個名稱/值對會對應到一個度量數目和度量數目的值。例如，代理程式度量訊息包含 12 個左右的度量數目的值，這些數目包括流入和流出代理程式的訊息數目和大小，以及目前記憶體中的訊息數目和大小等。如需每個度量訊息類型中報告的度量數目詳細資訊，請參閱Message Queue Java 用戶端開發人員指南，以瞭解如何寫入使用度量訊息的Message Queue 用戶端。

> 除了包含於度量訊息主體的度量資訊外，每個訊息標頭還有兩個特性：一個是指定度量訊息的類型，另一個是記錄時間標記。Message Queue 用戶端應用程式可使用這些標頭特性，以便從度量訊息擷取資料和記錄對應的時間標記。

> ##### 監視服務特性

> 表 2-9 中顯示代理程式的可配置特性，它們用於配置資訊的產生、記錄和度量訊息產生。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 表 2-9 監視服務特性

> 特性名稱 | 說明
> --- | ---
> imq.metrics.enabled | 指定 (true/false) 是否要將度量資訊寫入記錄程式。不會影響度量訊息的產生 (請參閱imq.metrics.topic.enabled)。 預設：true
> imq.metrics.interval | 如果已啟用度量記錄程式 (imq.metrics.enabled=true)，則請指定將度量資訊寫入記錄程式的時間間隔 (以秒為單位)。值 -1 表示永不報告。不會影響產生度量訊息的時間間隔 (請參閱imq.metrics.topic.interval)。 預設： -1
> imq.log.level | 指定記錄程式級別：可寫入至輸出通道的輸出種類。包括指定種類以及所有更高級的種類。從高至低的值為：ERROR、WARNING 和 INFO。 預設：INFO
> imq.log.file.output | 指定寫入至日誌檔的記錄資訊的種類。允許的值為：由垂直列 (|) 分隔的任何一組記錄種類，或者 ALL 或 NONE。 預設：ALL
> imq.log.file.dirpath | 指定包含日誌檔之目錄的路徑 (因作業系統而異)。 預設：請參閱附錄 A「Message Queue 資料的位置」
> imq.log.file.filename | 指定日誌檔的名稱。 預設： log.txt
> imq.log.file.rolloverbytes | 指定日誌檔輸出自動重建至新日誌檔時，此日誌檔的容量 (以位元組為單位)。值 -1 表示沒有基於檔案容量的自動重建。 預設： -1
> imq.log.file.rolloversecs | 指定日誌檔輸出自動重建至新日誌檔時，此日誌檔的存在時間 (以秒為單位)。值 -1 表示沒有基於檔案存在時間的自動重建。 預設： 604800 (一週)
> imq.log.console.output | 指定寫入至主控台的記錄資訊的種類。允許的值為由垂直列 (|) 分隔的任何一組記錄種類，或者 ALL 或 NONE。 預設：ERROR| WARNING
> imq.log.console.stream | 指定主控台輸出寫入至 stdout (OUT)，或寫入至 stderr (ERR)。 預設：ERR
> imq.log.syslog.facility | (僅適用於 Solaris) 指定 Message Queue 代理程式應記錄為的 syslog (系統日誌) 設備。值鏡射 syslog(3C) 線上援助頁中列出的那些值。用於 Message Queue 的適當值為：LOG_USER、LOG_DAEMON 以及 LOG_LOCAL0 至 LOG_LOCAL7。 預設：LOG_DAEMON
> imq.log.syslog.logpid | (僅適用於 Solaris) 指定是否同時記錄訊息與代理程式 ID (true/false)。 預設：true
> imq.log.syslog.logconsole | (僅適用於 Solaris) 指定如果訊息無法傳送至 syslog (系統日誌)，是否將它們寫入至系統主控台 (true/false)。 預設：false
> imq.log.syslog.identity | (僅適用於 Solaris) 指定應前置於每個訊息的身份字串是否記錄至 syslog (系統日誌)。 預設：imqbrokerd_ 以及代理程式實例名稱。
> imq.log.syslog.output | (僅適用於 Solaris) 指定寫入至 syslogd(1M) 的記錄資訊的種類。允許的值為由垂直列 (|) 分隔的任何記錄種類，或者 ALL 或 NONE。 預設：錯誤
> imq.log.timezone | 指定日誌時間標記的時區。這些識別碼與 java.util.TimeZone.getTimeZone()使用的識別碼相同。 例如：GMT、America/LosAngeles、Europe/Rome、Asia/Tokyo. 預設：本地時區
> imq.metrics.topic.enabled | 指定 (true/false) 是否啟用度量訊息產生功能。若為 false，那麼會拋出一個用戶端異常，表示嘗試指向度量主題目標。 預設：true
> imq.metrics.topic.interval | 指定產生傳送到度量主題目標之度量訊息的時間間隔 (以秒為單位)。 預設： 60
> imq.metrics.topic.persist | 指定 (true/false) 度量訊息是否為永久性訊息。 預設：false
> imq.metrics.topic.timetolive | 指定傳送到度量主題目標之度量訊息的有效期 (以秒為單位)預設值： 300

> ### 實體目標

> Message Queue 訊息傳送以兩個階段的訊息發送為前提：首先，從產生者用戶端至代理程式上的目標的訊息發送，然後，從代理程式上的目標至一個或多個使用者用戶端的訊息發送。有兩種類型的目標 (請參閱「程式設計網域」)：佇列 (點對點發送模型) 和主題 (出版/訂閱發送模型)。這些目標表示在代理程式實體記憶體中的位置，進來的訊息在路由至使用者用戶端之前，在這些位置進行整理。

> 您可以使用 Message Queue 管理工具建立實體目標 (請參閱「取得連接資訊」)。目標還可自動建立，如「自動建立的 (對應管理員建立的) 目標」中所述。

> 本節描述兩種類型實體目標的特性與運作方式：佇列與主題。

> #### 佇列目標

> 佇列目標用於點對點訊息傳送，其中訊息表示最終僅發送至已在目標中註冊其興趣的一些使用者之一。當訊息從訊息產生者到達時，它們會形成佇列並發送到單一訊息使用者。

> ##### 佇列發送至多個使用者

> 將佇列目標中的任何一個訊息僅發送給單一使用者時， Message Queue 允許多個使用者註冊佇列。代理程式會將進來的訊息路由到不同的使用者，以平衡負載。

> 實施到多個使用者的佇列發送，會根據以下的佇列目標屬性來使用一個可配置的負載平衡方法：

> - maxNumActiveConsumers： 指定在負載平衡的佇列發送中作用中使用者的數目 - 一個或多個。
> - maxNumBackupConsumers： 指定作用中使用者發生問題時，可以取代作用中使用者之備份使用者的數目 - 一個或多個。

> 如果使用者數目超過這兩個屬性的數目總和，將會拒絕新的使用者。(Message Queue 平台版在每個佇列最多支援 3 個使用者 - 兩個作用中使用者和一個備份使用者；Message Queue 企業版則支援無限個使用者。

> 負載平衡機制會考慮不同使用者的訊息使用率。它的運作方式如下：

> 在可配置大小的批次中，佇列目標中的訊息會路由到可用的新作用中使用者，以便使用者註冊佇列 (佇列目標的 consumerFlowLimit 屬性)。一旦發送這些訊息，其他到達佇列的訊息，會在使用者為可用狀態時 (即是使用者已使用一個訊息的可配置百分比，這些訊息先前已發送給使用者)，在批次中路由到使用者。每個使用者的派送比例根據使用者目前的容量和訊息處理比例而異。

> 訊息產生率低時，代理程式可能會不規則地派送訊息給作用中使用者。如果作用中使用者多於所需數目時，部分的使用者可能會收不到任何訊息。

> 如果作用中使用者發生問題，那麼第一個備份使用者會變成作用中狀態，且接手發生問題之使用者的工作。當佇列目標有一個以上的作用中使用者時，則無法保證訊息使用的順序。

> 在代理程式叢集環境中，可以將發送到多個使用者的功能，配置為先發送給本地使用者。佇列目標屬性 localDeliveryPreferred 可讓您指定只有在產生者的主代理程式沒有使用者時 - 意即產生者傳送訊息到代理程式 (本地代理程式)，才會將訊息發送給遠端使用者。在路由到遠端使用者 (透過使用者的主代理程式) 可能會降低流量速率的情況下，此配置可讓您增加路由到遠端使用者的效能。(此屬性要求目標範圍不僅限於本地發送，請參閱表 6-10。)

> ##### 記憶體注意事項

> 由於訊息可在佇列中保留較長一段時間，因此會出現記憶體資源問題。您不應為佇列配置太多的記憶體 (記憶體未完全利用)，也不應配置太少記憶體 (訊息可能被拒絕)。考慮到基於每個佇列載入需求的靈活性，您可在建立佇列時配置實體特性：佇列中訊息的最大數目、為佇列中訊息配置的最大記憶體，以及佇列中任何訊息的最大容量 (請參閱表 6-10)。

> #### 主題目標

> 主題目標用於出版/訂閱訊息傳送，其中訊息表示最終發送至已在目標中註冊其興趣的所有使用者。當訊息從產生者到達時，它們會被路由至訂閱此主題的所有使用者。如果使用者已註冊此主題的長期訂閱，則他們不會在訊息發送至此主題時成為作用中使用者 - 代理程式將儲存訊息直至使用者再次成為作用中使用者，然後發送訊息。

> 訊息通常不會在主題目標中保留較長一段時間，因此通常不會出現大的記憶體資源問題。但是，您可以配置目標 (請參閱表 6-10) 接收的任何訊息所允許的最大容量。

> #### 自動建立的 (對應管理員建立的) 目標

> 由於 Message Queue 訊息伺服器是訊息傳送系統中的中央集線器，因此其效能和可靠性對企業應用程式的成功相當重要。由於目標可使用大量資源 (取決於它們處理的訊息數目和容量，以及註冊的訊息使用者的數目和長期性)，因此它們需要嚴密管理，以確保訊息伺服器的效能和可靠性。因此，管理員的標準慣例即為建立作為應用程式的目標、監視目標，以及必要時重新配置它們的資源需求。

> 然而，也可能有希望動態建立目標的情況。例如，在開發及測試循環期間，您可能希望代理程式依需要自動建立目標，而不需要管理員的介入。

> Message Queue 支援這種自動建立功能。啟用自動建立後，每當 MessageConsumer 或 MessageProducer 嘗試存取不存在的目標時，代理程式便會自動建立目標。(用戶端應用程式的使用者必須擁有自動建立的權限，請參閱「目標自動建立存取控制」)。

> 但是，當自動建立而不是明確建立目標時，可能導致不同的用戶端應用程式 (使用相同的目標名稱) 之間的衝突，或降低系統效能 (歸因於支援目標所需的資源)。由於此原因，當不再使用自動建立的目標時，此目標將被代理程式自動銷毀：即，當此目標不再有訊息使用者用戶端且不再包含任何訊息時。如果代理程式重新啟動，則它將僅重新建立自動建立的目標 (如果這些目標它們包含永久性訊息)。

> 您可以使用表 2-10 中所示的特性配置 Message Queue 訊息伺服器，以啟用或停用自動建立功能。(如需有關配置這些特性的說明，請參閱第 5 章「啟動與配置代理程式」)

> 表 2-10 自動建立配置特性

> 特性名稱 | 說明
> --- | ---
> imq.autocreate.topic | 指定是否允許代理程式自動建立主題目標 (true/false)。 預設：true
> imq.autocreate.queue | 指定是否允許代理程式自動建立佇列目標 (true/false)。 預設：true
> imq.autocreate.destination. maxNumMsgs | 指定自動建立的目標中，允許給未使用訊息的最大數目。 預設： 100,000
> imq.autocreate.destination. maxTotalMsgBytes | 指定目標中允許給未使用訊息的最大總記憶體容量 (以字元組為單位)。 預設：10m (百萬位元組)
> imq.autocreate.destination. limitBehavior | 指定達到記憶體限制執行緒時，代理程式確認的方式。值為： FLOW_CONTROL - 減緩產生者速度 REMOVE_OLDEST - 拋出最舊的訊息 REMOVE_LOW_PRIORITY - 根據訊息存在時間拋出具最低優先權的訊息 REJECT_NEWEST - 拒絕最新的訊息 預設：REJECT_NEWEST
> imq.autocreate.destination. maxBytesPerMsg | 指定自動建立的目標中允許的任何單一訊息的最大容量 (以位元組為單位)。 預設：10k (10,240)
> imq.autocreate.destination. maxNumProducers | 指定允許給目標中產生者的最大數目。達到限制時，將無法建立新的產生者。 預設： 100
> imq.autocreate.destination. isLocalOnly | 僅適用於代理程式叢集。指定在其他代理程式上不重複目標，且限制目標僅發送訊息給本地使用者 (連接到目標上所建立之代理程式的使用者)。一旦建立目標，即無法更新屬性。 預設：false
> imq.autocreate.queue. maxNumActiveConsumers | 指定最大使用者數，此數值可作用於來自自動建立之佇列目標的負載平衡發送。值 -1 表示沒有限制數目。 預設： 1
> imq.autocreate.queue. maxNumBackupConsumers | 指定最大備份使用者數，如果無法從自動建立的佇列目標進行負載平衡發送，那麼這些使用者可以取代作用中的使用者。值 -1 表示沒有限制數目。 預設： 0
> imq.autocreate.queue. consumerFlowLimit | 指定最大訊息數目，這些訊息將會發送給單一批次中的某個使用者。在負載平衡佇列發送中，負載平衡開始前，此數目是路由到作用中使用者的佇列訊息初始數目。 (請參閱「佇列發送至多個使用者」)。目標的使用者在其個別連接上，可配置一個較低的值來置換此限制 (請參閱「Message Queue Java 用戶端開發人員指南」中連線工廠屬性的相關資訊)。值 -1 表示沒有限制數目。 預設： 1000
> imq.autocreate.topic. consumerFlowLimit | 指定最大訊息數目，這些訊息將會發送給單一批次中的某個使用者。值 -1 表示沒有限制數目。 預設： 1,000
> imq.autocreate.queue. localDeliveryPreferred | 僅適用於代理程式叢集中的負載平衡佇列發送。如果本地代理程式沒有使用者，則指定訊息僅發送給遠端使用者。要求自動建立的目標不僅限於本地發送 (isLocalOnly = false)。 預設：false

> #### 暫存目標

> 暫存目標由用戶端明確建立和銷毀 (使用 JMS API)，這些應用程式需要目標以接收傳送至其他用戶端的訊息回覆。這些目標由代理程式維護，僅用於為建立目標所需連接的持續時間。只要暫存目標處於使用中，它無法由管理員銷毀，也無法由用戶端應用程式銷毀：即，如果它有作用中的訊息使用者。暫存目標不同於管理員建立的或自動建立的目標 (包含永久性訊息)，它們無法永久儲存，且當重新啟動代理程式時從不重新建立。但是，它們對於 Message Queue 管理工具而言為可視 (請參閱表 6-9)。

> ### 多重代理程式叢集 (企業版)

> Message Queue 企業版支援使用多重互連的代理程式實例 (代理程式叢集) 的訊息伺服器的實施。叢集支援提供訊息伺服器的延展性。

> 隨著連接至代理程式的用戶端數目的增加，以及要發送的訊息數目的增加，代理程式將最終超過資源限制 (如檔案描述元和記憶體限制)。提供增加載入的一個方法為將多個代理程式 (即多個代理程式實例) 新增至 Message Queue 訊息伺服器，從而在多重代理程式間分布用戶端連接和訊息發送。

> 您還可以使用多重代理程式最適化網路頻寬。例如，您可以在一組遠端代理程式間使用較慢、距離較長的網路連結，而使用較高速度的連結將用戶端連接至其各自的代理程式實例。

> 然而，使用代理程式叢集還有其他原因 (例如，提供具有不同使用者儲存庫的工作群組，或處理防火牆限制)，但故障轉移不是這些原因之一。當 Message Queue 允許使用叢集中不同的代理程式來重新建立失敗的連接時，將會遺失狀態資訊。因此，叢集中的代理程式無法用作出現故障的其他代理程式的自動備份。

> 換句話說，Message Queue 目前不支援高度可用性的訊息伺服器。但是，您可以使用 Sun Cluster 軟體和提供代理程式故障轉移的高度可用資料庫。您也可以設計一個訊息傳送應用程式，以使用多個代理程式來實施自訂的故障轉移解決方案。

> 「使用叢集 (企業版)」 中提供有關配置和管理代理程式叢集的資訊。

> 以下各節介紹 Message Queue 代理程式叢集的架構和內部功能。

> #### 多重代理程式架構

> 多重代理程式訊息伺服器允許用戶端連接分布在一些代理程式實例中，如圖 2-7 中所示。從用戶端的角度看，每個用戶端均連接至個別代理程式 (它的主代理程式)，並傳送和接收訊息，猶如此主代理程式為叢集中唯一的代理程式。但是，從訊息伺服器的角度看，主代理程式與叢集中的其他代理程式以串聯方式工作，為訊息生產者以及與其直接連接的使用者提供發送服務。

> 理論上，叢集中的代理程式可用任一隨機拓撲連接。但是，Message Queue 僅支援完全連接的叢集 (即拓撲)，在拓撲中每個代理程式均直接連接至叢集中所有其他代理程式，如圖 2-7 中所示。

> 圖 2-7 多重代理程式 (叢集) 架構

> ##### 訊息發送

> 在多重代理程式配置中，叢集中所有代理程式上均會重複每個目標。(儘管會發生一些異常，叢集環境中的目標屬性通常會整個套用到目標的所有實例，意即套用到整個叢集，而非套用到個別的目標實例。再者，isLocalOnly 屬性設為 true 的目標在叢集裡不會被重複。如需更多資訊，請參閱目標屬性說明：表 6-10。)

> 每個代理程式均瞭解已註冊所有其他代理程式之目標的訊息使用者。因此，每個代理程式均可將訊息從其直接連接的訊息產生者路由至遠端訊息使用者，並將訊息從遠端產生者發送至其直接連接的使用者。

> 在叢集配置中，與每個訊息產生者直接連接的代理程式為此產生者傳送至它的訊息執行路由。因此，永久性訊息由其主代理程式儲存和路由。

> 若要最小化叢集裡代理程式間的流量，訊息發送 (從目標到用戶端運行時間) 受到使用者連接上的流量控制機制所牽制。在此方法中，只有在訊息將發送給連接到目標代理程式的使用者時，才會將訊息從一個代理程式傳送到另一個代理程式，從而避免將不需要的訊息從一個代理程式傳送到另一個代理程式。同時，在某些情況下，例如到多個使用者的佇列發送情況下，您可以最小化代理程式間的流量，方法為指定優先發送到本地使用者，之後再發送到遠端使用者 (請參閱localDeliveryPreferred 佇列目標屬性，表 6-10)。

> 某些情況要求用戶端和訊息伺服器間實現安全的加密訊息發送，此時可以對叢集配置，使叢集中代理程式間的訊息發送也實現安全性 (請參閱「安全代理程式互通連接」)。

> ##### 叢集同步化

> 每當管理員在代理程式上建立或銷毀目標時，此資訊會自動傳遞至叢集中所有其他代理程式。同樣，每當訊息使用者註冊其主代理程式，或使用者與其主代理程式中斷連接 (明確中斷連接，或者因為用戶端或網路故障，或者因為其主代理程式出現故障) 時，有關使用者的相關資訊會在叢集中傳遞。在類似方式中，有關長期訂閱的資訊也會傳遞至叢集中的所有代理程式。

> 備註 | 大量的網路流量和/或大量訊息可阻礙內部叢集連接。增加的等待時間有時可導致鎖定協定逾時錯誤。結果，用戶端可能在嘗試建立長期用戶或佇列訊息使用者時出現異常。使用較高速度的連接通常可避免這些問題。

> 將有關目標和訊息使用者的資訊傳遞至特定代理程式，通常會要求當共用資源發生變更時此代理程式應在線上。如果當進行此類變更時代理程式離線 (例如，如果代理程式故障且隨後重新啟動，或者如果將新代理程式動態新增至叢集)，將會如何？

> 為了提供已離線的代理程式 (或已新增的新代理程式)，Message Queue 將保留對叢集中所有永久性實體所作變更的記錄。即，已建立或銷毀的所有目標與所有長期訂閱的記錄。當代理程式動態新增至叢集時，它先從此配置變更記錄中讀取目標和長期用戶資訊。當它上線後，它將與其他代理程式交換有關目前作用中的使用者的資訊。新代理程式可使用此資訊完全整合至叢集。

> 配置變更記錄由叢集中的代理程式之一 (即指定為主代理程式的代理程式) 管理。由於主代理程式對於將代理程式動態新增至叢集極為關鍵，因此您應始終先啟動此代理程式。如果主代理程式不在線上，則叢集中的其他代理程式將無法完成它們的初始化。

> 如果主代理程式離線，則其他代理程式則無法存取配置變更記錄，而且 Message Queue 將不允許目標和長期訂閱在叢集中傳遞。在這些情況下，如果您嘗試建立或銷毀目標或長期訂閱 (或嘗試執行一些重新啟動長期訂閱之類的相關作業)，則會出現異常。

> 在任務重要的應用程式環境中，應定期備份配置變更記錄，以防止意外損毀記錄並避免主代理程式發生故障。您可以使用 imqbrokerd 指令的 -backup 選項 (請參閱表 5-2) 執行此作業，此選項可提供建立包含配置變更記錄的備份檔案的方法。隨後，您可以使用 -restore 選項復原此配置變更記錄。

> 如有必要，您可以透過備份配置變更記錄及修改適當的叢集配置特性 (請參閱表 5-3) 來變更作為主代理程式服務的代理程式，以指定新的主代理程式，並使用 -restore 選項來重新啟動此新的主代理程式。

> #### 使用開發環境中的叢集

> 在開發環境中，叢集用於測試，而延展性與代理程式回復並非重要注意事項，因此不需要主代理程式。在未配置主代理程式的環境中，Message Queue 不需要主代理程式處於執行狀態以啟動其他代理程式，並且允許對目標與長期訂閱進行變更並將它們傳遞至叢集中所有執行中的代理程式。但是，如果代理程式離線並隨後復原，則它將不會與其離線時所作的變更同步。

> 在測試情況下，目標通常是自動建立的 (請參閱「自動建立的 (對應管理員建立的) 目標」)，這些目標的長期訂閱由要進行測試的應用程式建立和銷毀。對目標和長期訂閱所作的這些變更將在叢集中傳遞。但是，如果您重新配置環境以使用主代理程式，則 Message Queue 將重新強加需求，即主代理程式處於執行狀態，以便對目標與長期訂閱進行變更，並使這些變更在叢集中傳遞。

> #### 叢集配置特性

> 叢集中的每個代理程式必須在啟動時傳送有關叢集中其他代理程式的資訊 (主機名稱與連接埠號)。此資訊用於在叢集中的代理程式之間建立連接。每個代理程式還必須知道主代理程式 (如果已使用) 的主機名稱和連接埠號。

> 叢集中的所有代理程式皆應使用一組共用的叢集配置屬性。透過將叢集配置特性放在啟動時每個代理程式均參考的一個中央叢集配置檔案中，您便可以達到此共通性。

> 您還可以複製叢集配置特性，並分別將它們提供給每個代理程式。但是，不建議這樣做，因為它可能導致叢集配置的不一致性。僅保留叢集配置特性的副本可確保所有代理程式均參閱相同的資訊。

> 如需有關叢集配置特性的更多資訊，請參閱「使用叢集 (企業版)」。

> 叢集配置檔案可用於儲存一組代理程式共用的所有代理程式配置特性。儘管它原先專用於配置叢集，但是它還可用於儲存叢集中所有代理程式共用的其他代理程式特性。

> ##

> Message Queue 用戶端運行時間

> Message Queue 用戶端運行時間提供到 Message Queue 訊息服務的介面給用戶端應用程式 - 它提供「JMS 程式設計模型」 中介紹的所有 JMS 程式設計物件給 Java 用戶端應用程式，並提供對應的 C 介面給 C 用戶端應用程式。Message Queue 用戶端運行時間支援用戶端將訊息傳送至目標，和從此類目標接收訊息所需的所有作業。

> 本節提供 Message Queue 用戶端運行時間如何工作的詳細描述。Message Queue Java 用戶端開發人員指南和Message Queue C 用戶端開發人員指南中個別說明影響 Java 用戶端運行時間和 C 用戶端運行時間的用戶端應用程式設計和效能的因素。

> 圖 2-8 說明訊息生產與使用如何在用戶端應用程式與 Message Queue 用戶端運行時間之間進行互動，而訊息發送如何在 Message Queue 用戶端運行時間與 Message Queue 訊息伺服器之間進行互動。

> 圖 2-8 訊息傳送作業

> ### 訊息生產

> 在訊息生產中，訊息由用戶端建立，並透過連接傳送至代理程式上的目標。如果 MessageProducer 物件的訊息遞送模式已配置為永久性 (可確保的遞送，一次且僅有一次)，則用戶端執行緒會封鎖，直至此代理程式確認訊息已遞送至其目標並儲存在代理程式的永久性資料倉庫中。如果訊息不是永久性的，則代理程式不會傳回代理程式確認訊息 (在特性名稱中稱為「Ack」)，並且用戶端執行緒不會封鎖。

> ### 訊息使用

> 訊息使用比生產更為複雜。在以下條件下，到達代理程式上目標的訊息會透過連接發送至 Message Queue 用戶端運行時間：

> - 用戶端已為給定的目標配置使用者
> - 使用者的選取條件 (如果有) 符合到達給定目標的訊息的條件
> - 系統已告知連接啟動訊息發送。

> 透過連接發送的訊息分布至適當的 Message Queue 階段作業，在此階段作業中，這些訊息形成佇列以供適當的 MessageConsumer 物件使用，如圖 2-9 中所示。訊息從每個階段作業佇列取回，每次一個 (階段作業為單一執行緒的)，並同步使用 (透過呼叫 receive 方法的用戶端執行緒) 或非同步使用 (透過呼叫 MessageListener 物件的 onMessage 方法的階段作業執行緒)。

> 圖 2-9 訊息發送至 Message Queue 用戶端運行時間

> 當代理程式將訊息發送至用戶端運行時間時，它會相應地標記訊息，但無法真正知道它們是否已被接收或使用。因此，在將訊息從代理程式目標刪除之前，代理程式會等待用戶端確認訊息的接收。

> ##

> Message Queue受管理物件

> 受管理物件允許用戶端應用程式碼獨立於供應程式。透過將供應程式特定的實施與配置資訊封裝在由用戶端應用程式，以獨立於供應程式的方式使用的物件中，它們可達到此目的。受管理物件由管理員建立和配置，儲存在名稱服務中，並由用戶端應用程式透過標準的 JNDI 查找程式碼存取。

> Message Queue 提供兩種類型的受管理物件：ConnectionFactory 與 Destination。當這兩種類型的受管理物件封裝供應程式特定的資訊時，它們會使用完全不同的用戶端應用程式。ConnectionFactory 物件用於建立與訊息伺服器的連接，而 Destination (目標) 物件則用於識別實體目標。

> 受管理物件使控制和管理 Message Queue 訊息伺服器變得非常容易：

> - 透過要求用戶端應用程式存取預先配置的 ConnectionFactory 物件 (請參閱「連線工廠受管理物件屬性」)，您可以控制連接的運作方式。
> - 透過要求用戶端應用程式存取與現有實體目標相符的預先配置的 Destination (目標) 物件，您可以控制實體目標的激增。(您還必須停用代理程式的自動建立功能，請參閱「自動建立的 (對應管理員建立的) 目標」)。
> - 透過置換用戶端應用程式配置的訊息標頭值 (請參閱「連線工廠受管理物件屬性」)，您可以控制 Message Queue 訊息伺服器資源。

> 因此，此排序可讓您 (作為 Message Queue 管理員) 控制訊息伺服器配置的詳細資訊，同時還允許用戶端應用程式獨立於供應程式：它們不必瞭解供應程式特定的語法和物件命名慣例 (請參閱「JMS 提供者獨立性」)，或供應程式特定的配置特性。

> 您可以使用 Message Queue 管理工具來建立受管理物件，如第 7 章「管理受管理物件」中所述。建立受管理物件時，您可以將物件指定為唯讀 - 即防止用戶端應用程式變更建立物件時已配置的 Message Queue 特定的配置值。換言之，用戶端程式碼無法配置有關唯讀受管理物件的屬性值，您也無法使用用戶端應用程式啟動選項來置換這些值，如「啟動用戶端時置換屬性值」中所述。

> 而用戶端應用程式可在其上創設 ConnectionFactory 和 Destination (目標) 受管理物件，此做法會逐漸損壞受管理物件的基本用途 - 可讓您 (作為 Message Queue 管理員) 控制應用程式所需的代理程式資源，並調整其效能。此外，直接創設受管理物件可使用戶端應用程式為供應程式特定的，而不是獨立於供應程式的。

> ### 連線工廠受管理物件

> ConnectionFactory 物件用於在用戶端應用程式與 Message Queue 訊息伺服器之間建立實體連接。它還用於指定連接與用戶端運行時間的運作方式，此用戶端運行時間使用連接存取代理程式。

> 如果您希望支援分散式異動 (請參閱「本地異動」)，則需要使用可支援分散式異動的特殊 XAConnectionFactory 物件。

> 若要建立 ConnectionFactory 受管理物件，請參閱「新增連線工廠」。

> 透過配置 ConnectionFactory 受管理物件，您可以指定此受管理物件生產的所有連接共用的屬性值 (特性)。ConnectionFactory 與 XAConnectionFactory 物件共用同一組屬性。根據這些屬性影響的運作方式，可將它們群組為一些種類：

> - 連接規格
> - 自動重新連接運作方式
> - 用戶端識別
> - 訊息標頭置換
> - 可靠性與流量控制
> - 佇列瀏覽器運作方式
> - 應用程式伺服器支援
> - JMS 定義的特性支援

> Message Queue Java 用戶端開發人員指南中詳細說明了這些種類中的各項目及其相應的屬性。而系統可能要求您 (作為 Message Queue 管理員) 調整這些屬性的值，通常由應用程式開發人員決定需要調整哪些屬性以調整用戶端應用程式的效能。表 7-3 描述了按字母順序列出的屬性摘要。

> ### 目標受管理物件

> Destination (目標) 受管理物件表示代理程式中的實體目標 (佇列或主題)，共用名稱為 Destination (目標) 的物件與此實體目標相符。表 2-11 中描述了它的兩個屬性。透過建立 Destination (目標) 物件，您可允許用戶端應用程式的 MessageConsumer 和/或 MessageProducer 物件來存取對應的實體目標。

> 若要建立 Destination (目標) 受管理物件，請參閱「新增主題佇列」。

> 表 2-11 目標屬性

> 屬性/特性名稱 | 說明
> --- | ---
> imqDestinationName | 指定供應程式特定的實體目標名稱。您可在建立實體目標時指定此名稱。目標名稱必須僅包含字母數字字元 (無空格)，並且以字母字元或字元「_」和「$」開頭。它們不可以以「mq」字元字串開頭。 預設： Untitled_Destination_Object
> imqDestinationDescription | 指定對管理物件有用的資訊。 預設：A Description for the Destination Object

> ### 啟動用戶端時置換屬性值

> 如同任何 Java 應用程式，您可以使用指令行啟動訊息傳送應用程式，以指定系統特性。此機制還可用於置換受管理物件的屬性值，這些屬性值用於用戶端應用程式碼。例如，您可以置換受管理物件的配置，此受管理物件可在用戶端應用程式碼中透過 JNDI 查找存取。

> 若要在啟動用戶端應用程式時置換受管理物件的配置，您可以使用以下指令行語法：

> java [[-Dattribute=value ]...] clientAppName

> 其中，attribute 與「連線工廠受管理物件屬性」中提供的任何 ConnectionFactory 受管理物件屬性相符。

> 例如，如果您要將用戶端應用程式連接至不同的代理程式，而不是在用戶端程式碼中存取的 ConnectionFactory 受管理物件中所指定的代理程式，您可以使用指令行置換來啟動用戶端應用程式，以配置其他代理程式的 imqBrokerHostName 和 imqBrokerHostPort。

> 但是，如果受管理物件已配置為唯讀，則使用指令行置換無法變更其屬性值。任何此類置換均被完全忽略。

> 上一章 目錄 索引 下一章

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.