脈絡：企業正用訊息傳遞整合應用程式。

訊息在被轉送前該存在哪裡#

非同步訊息相對於 RPC 的主要優勢之一，就是寄件端、接收端與連接兩者的網路不必同時運作：

• 網路不通時，訊息系統必須把訊息存起來，直到網路恢復
• 接收端不可用時，訊息系統必須存起訊息並重試遞送，直到接收端恢復

這正是訊息傳遞所依據的儲存後轉送流程。那麼在轉送之前，訊息該存在哪？

預設情況下，訊息系統把訊息存在記憶體中，直到能成功轉送到下一個儲存點。只要訊息系統穩定運行，這行得通；但訊息系統一旦崩潰（機器斷電、訊息行程意外中止），所有存在記憶體中的訊息就全部遺失。

多數應用程式都得面對類似問題：存在記憶體的資料在崩潰時會遺失，所以應用程式用檔案與資料庫把資料持久化到磁碟，好讓它撐過系統崩潰。訊息系統也需要類似的機制。

解法#

運作方式：

• 訊息系統用內建的資料儲存來持久化訊息；它安裝的每台電腦都有自己的資料儲存，訊息因此能在本地保存。
• 寄件端送出訊息時，送出操作要等到訊息安全地存進寄件端的資料儲存後才算成功完成。
• 之後，訊息在成功轉送並存入下一個資料儲存之前，不會從前一個資料儲存中刪除。

如此一來，寄件端一旦成功送出訊息，它就始終至少存在一台電腦的磁碟上，直到成功遞送給接收端並被確認為止。

代價#

• 效能——持久化提高可靠性，代價是效能。若訊息系統崩潰或關閉時遺失訊息是可以接受的，就別用 Guaranteed Delivery，讓訊息在系統中跑得更快。

• 磁碟空間——在高流量情境下 Guaranteed Delivery 可能吃掉大量磁碟空間。若生產者每秒產出數百至數千則訊息，一次持續數小時的網路中斷就可能耗用驚人的磁碟空間；而且因為網路不通，訊息只能存在生產端本機磁碟上，而那顆磁碟未必是為了裝這麼多資料而設計的。

因此有些訊息系統允許設定重試逾時參數，指定訊息在系統內被緩衝多久。在某些高流量應用中（例如把股票報價串流到終端機），這個逾時可能得設得很短，例如幾分鐘。

所幸在許多這類應用中，訊息被當作 Event Message 使用，經過短暫時間後可以安全丟棄（見 Message Expiration）。

測試與除錯時記得關掉#

在測試與除錯期間關閉 Guaranteed Delivery 很有用——這樣只要停掉再重啟訊息伺服器，就能清空所有通道。

佇列中殘留的訊息會讓除錯連最簡單的訊息程式都變得極其煩人。例如寄件端與接收端由一個 Point-to-Point Channel 相連，若通道上還留著一則舊訊息，接收端會先處理那則舊訊息，才輪到寄件端新產生的訊息——這是非同步、保證送達情境下常見的除錯陷阱。

許多商業訊息實作也允許你個別清空佇列，以便測試時重新開始。

與其他模式的搭配#

• 在 .NET 的 MSMQ 實作中，通道要持久化就必須宣告為交易性的，這意味著寄件端通常得是 Transactional Client。
• 在 JMS 中，對 Publish-Subscribe Channel 而言，Guaranteed Delivery 只保證訊息會送達當時活躍的訂閱者。要確保訂閱者在非活躍期間也收得到，它必須是 Durable Subscriber。

Session session = // obtain the session
Destination destination = // obtain the destination
Message message = // create the message
MessageProducer producer = session.createProducer(destination);
producer.send(
          message,
          javax.jms.DeliveryMode.PERSISTENT,
          javax.jms.Message.DEFAULT_PRIORITY,
          javax.jms.Message.DEFAULT_TIME_TO_LIVE);

producer.setDeliveryMode(javax.jms.DeliveryMode.PERSISTENT);

producer.send(message);

DEFINE Q(myQueue) PER(PERS)

DEFINE Q(myQueue) PER(APP)

MessageQueue.Create("MyQueue", true);