Azure 服務匯流排 - 訊息到期 (存留時間)

  • 發行項

訊息內的承載 (或是訊息傳遞給接收者的命令或查詢) 幾乎一律受限於某種形式的應用程式層級到期期限。 在這類期限之後，系統便不再提供內容，或者不再執行要求的作業。

對於通常會在應用程式或應用程式組件的部分執行內容中使用佇列和主題的開發與測試環境，它也很適合用來將擱置的測試訊息自動進行記憶體回收，如此一來，就能全新開始下一個測試執行。

注意

如果您還不熟悉服務匯流排概念，請參閱服務匯流排概念，以及服務匯流排佇列、主題和訂閱。

任何個別訊息的到期都能透過設定 time-to-live 系統屬性來控制，其會指定相對的持續期間。 將訊息加入實體的佇列時，到期就會變成絕對瞬間。 在那段時間，expires-at-utc 屬性會採用 enqueued-time-utc + time-to-live 的值。 當沒有用戶端在主動接聽時，代理訊息上的存留時間 (TTL) 設定不會強制執行。

經過 expires-at-utc 瞬間之後，訊息就會變得不適合用於擷取。 到期時間並不會影響到目前鎖定在傳遞狀態的訊息。 這些訊息仍會正常處理。 如果鎖定到期或已放棄訊息，則到期將會立即生效。 儘管訊息處於鎖定狀態，但應用程式可能擁有已到期的訊息。 應用程式是否願意繼續進行處理，或選擇放棄訊息，都取決於實作者。

以毫秒或秒為單位計算的極短 TTL 可能會導致訊息在接收者應用程式收到之前過期。 請考慮將 TTL 設置為適用於您應用程式的最高限度。

注意

針對已排程的訊息，您可以指定佇列中要讓訊息具體化以便擷取的加入佇列時間。 訊息傳送至服務匯流排的時間，與訊息加入佇列的時間不同。 訊息到期時間取決於加入佇列的時間，而不是訊息傳送至服務匯流排的時間。 因此，到期時間 (UTC) 仍為加入佇列的時間 + 存留時間。

例如，如果您將 ScheduledEnqueueTimeUtc 設定為 UtcNow 後的 5 分鐘，而 TimeToLive 設定為 10 分鐘，則訊息將在 5 + 10 = 15 分鐘後過期。 訊息在 5 分鐘後出現在佇列中，10 分鐘計數器從那時開始。

實體層級的到期

所有傳遞到佇列或是主題的訊息，都會受到在實體層級設定的預設到期時間的影響。 您也可以在建立期間於入口網站中設定，並在稍後再加以調整。 預設的到期適用於所有傳送至實體且未明確設定存留時間的訊息。 預設到期也可用來作為存留時間值的上限。 若訊息的存留時間到期比預設值還長，則會在加入佇列之前，以無訊息方式調整為預設的存留時間值。

注意

  • 如果未明確指定，則代理訊息的預設存留時間值是帶正負號 64 位整數的最大可能值。
  • 針對傳訊實體 (佇列和主題)，服務匯流排標準和進階層的預設到期時間也是帶正負號 64 位整數的最大可能值。 在基本層中，預設 (以及最長) 到期時間為 14 天。
  • 如果主題指定的 TTL 小於訂閱，則會套用主題 TTL。

過期的訊息可以選擇性地移至無效信件佇列。 您可以透過程式設計方式，或使用 Azure 入口網站來設置此設定。 如果將選項保留為已停用，即會卸除過期的訊息。 移至無效信件佇列的過期訊息可以藉由評估訊息代理程式儲存於使用者屬性區段的無效信件原因屬性來區分。

若訊息會受到了保護以免在鎖定下到期，而且如果在實體上設定旗標，則會在放棄鎖定或鎖定到期時，將訊息移到無效信件佇列。 不過，如果已成功安置訊息則不會加以移動，接著，儘管名義上已到期，還是假設應用程式已成功處理它。 如需訊息鎖定和安置的詳細資訊，請參閱訊息傳輸、鎖定和安置。

期滿的存留時間和自動執行 (和交易式) 無效信件組合是個非常重要的工具，讓您有信心在到達期限時，能夠擷取指定給某個處理常式或一組處理常式且未達期限的作業來處理。

例如，假設有個網站需要在有限範圍的後端上可靠地執行作業，而且偶爾會經歷流量尖峰，或者想要根據該後端的可用性事件來隔離。 在正常情況下，適用於已提交使用者資料的伺服器端處理常式會將資訊推入佇列，隨後會收到回覆，確認已成功將交易處理至回覆佇列中。 如果出現流量尖峰且後端處理常式無法即時處理其待處理項目，則會傳回無效字母佇列上的過期作業。 互動式使用者會收到通知，表示要求的作業需要比平常多一點的時間，接著可將要求放入處理路徑的不同佇列，以便透過電子郵件來將最終處理結果傳送給使用者。

已啟用工作階段之實體的到期日

針對已啟用工作階段的佇列或主題的訂閱，訊息會在工作階段層級遭到鎖定。 如果任何訊息的 TTL 到期，則根據實體上訊息到期設定啟用的無效字母，與該工作階段相關的所有訊息都將遭到刪除或變成無效字母。 換句話說，如果工作階段中只有一則訊息超過了 TTL，則該工作階段中的所有訊息都視為到期。 只有當存在使用中接聽程式時，訊息才會到期。

暫時性實體

您可以將服務匯流排佇列、主題和訂用帳戶建立為暫時性實體，若經過一段指定的時間未使用它們，即會自動移除。

自動清除適用於開發和測試案例，在這類案例中會動態建立實體，並且不會在使用之後加以清除，因為測試或偵錯執行發生部分中斷。 當應用程式針對接收回到 Web 伺服器處理序的回應建立動態實體 (例如回覆佇列)，或者建立到另一個相對存留期較短的物件 (當物件執行個體消失時，就很難在其中可靠地清理那些實體) 時，也很適合使用。

此功能是藉由命名空間上的閒置時自動刪除屬性來啟用的。 這個屬性是設定自動刪除實體之前，實體必須閒置 (未使用) 的持續時間。 此屬性的最小值為 5 分鐘。

重要

將 Azure Resource Manager 鎖定層級設定為 CanNotDelete，並不會在命名空間或較高層級防止刪除具有 AutoDeleteOnIdle 的實體。 如果您不想刪除實體，請將 AutoDeleteOnIdle 屬性設定為 DataTime.MaxValue。

閒置

以下是會視為實體閒置的行為 (佇列、主題和訂用帳戶)：

實體 會被視為閒置的內容
Queue
  • 沒有傳送
  • 沒有接收
  • 沒有對佇列的更新
  • 沒有排定的訊息
  • 沒有瀏覽/查看
主題
  • 沒有傳送
  • 沒有對主題的更新
  • 沒有排定的訊息
  • 主題的訂閱上沒有任何作業 (請參考下個資料列)
訂用帳戶
  • 沒有接收
  • 沒有對訂用帳戶的更新
  • 沒有新規則新增到訂用帳戶
  • 沒有瀏覽/查看

重要

如果您在佇列或訂閱上設定了自動轉送，則相當於有一個接收者在佇列或訂閱上執行接收，並且它們不會閒置。

SDK

下一步

若要深入了解服務匯流排傳訊，請參閱下列文章：