包含命名空間主題的訊息推送傳遞和重試

事件方格命名空間推送傳遞可提供持久的傳遞。 事件方格會立即嘗試傳遞每個相符訂閱的每則訊息，至少一次。 如果訂閱者的端點未確認收到事件，或如果發生失敗，事件方格會根據固定重試排程和重試原則重試傳遞。 依預設，[事件方格] 一次會將一個事件傳遞給訂閱者。

注意

事件方格不保證事件傳遞的順序，因此訂閱者可能不會依序收到事件。

事件訂閱

事件訂閱是與單一命名空間主題相關聯的設定資源。 除此之外，您可以使用事件訂用帳戶來設定事件選取準則，以定義主題中可用事件總數集的訂閱者適用事件集合。 使用事件訂閱也要定義傳送事件的目的地端點。 此外，事件訂閱可讓您設定其他屬性，例如傳遞重試次數上限和事件存留時間等可定義事件傳遞的執行階段行為。

重試排程

當事件方格收到事件傳遞嘗試錯誤時，事件方格會決定是否應根據錯誤類型重試傳遞。

如果已訂閱端點傳回的錯誤是無法經重試修正的設定相關錯誤，事件方格會將事件傳送至設定的無效信件目的地。 如未設定任何無效信件，則卸除該事件。 例如，當事件訂閱上已設定的端點因遭刪除而無法連線時，事件即為無效信件或予以卸除。 下列情況和錯誤不會重試傳遞:

條件：

• ArgumentException
• TimeoutException
• UnauthorizedAccessException
• OperationCanceledException
• SocketException |

錯誤碼

• 404 - NotFound
• 401 - Unauthorized
• 403 - Forbidden
• 400 -BadRequest
• 414 RequestUriTooLong

注意

端點如未設定無效信件，當發生上述錯誤或情況時，就會卸除事件。 如果不想卸除這類事件，請考慮為事件訂閱設定無效信件。 找不到無效信件目的地時，將會卸除無效信件事件。

如果已訂閱端點傳回的情況或錯誤不在上述清單中，事件方格會使用下列指數輪詢重試排程，依基礎投入量重試:

• 0 秒 (立即重試)
• 10 秒
• 30 秒
• 1 分鐘
• 5 分鐘

5 分鐘之後，事件方格會繼續每隔 5 分鐘重試一次，直到事件傳遞完成，或者達到重試次數上限或事件存留時間。

重試原則

您可以使用下列兩個事件訂閱設定屬性來自訂重試原則。 如果任一屬性達到設定限制，則會卸除事件 (未設定無效信件時) 或列為無效信件。

• 傳遞計數上限 - 此值必須為介於 1 到 10 之間的整數。 預設值為 10。 針對推送傳遞，此屬性會定義傳遞嘗試次數上限。
• 保留 - 這個屬性也稱為 event time to live。 此值必須是以分鐘計的 ISO 8601 持續時間值。 這個屬性會定義從事件發佈時間開始到訊息到期的時間範圍。 允許的最小值為 "PT1M" (1 分鐘)。 允許值上限為 7 天或基礎主題的保留時間，以較低者為準。 Azure 入口網站提供簡單的使用者體驗，供您指定整數的天數、小時數和分鐘數。

注意

如果同時設定 Retention 和 Maximum delivery count，事件方格就會使用此二者判斷何時停止傳遞事件。 二者之一會停止事件傳遞。 例如，如果您設定 20 分鐘的保留時間和傳遞嘗試次數上限 10 次，即表示事件會在 20 分鐘後不予傳遞或在嘗試 10 次後不予傳遞，無論哪種情況先發生，事件都會列為無效信件。 但因重試排程之故，將傳遞嘗試次數上限設定為 10 次不會有影響，因為事件會在 20 分鐘後先成為無效信件。 這是因為在 20 分鐘時，傳遞嘗試次數達到 #8 (0、10 秒、30 秒、1 分鐘、5 分鐘、10 分鐘、15m 分鐘、20 分鐘)，而此時事件已為無效信件。

輸出批次

當您以 Webhook 為目的地端點類型時，事件方格預設會將每個事件一一傳送給訂閱者。 您可以設定事件方格批次傳遞事件，以提高高輸送量案例的 HTTP 效能。 預設關閉批次處理，可依事件訂閱個別開啟。

以事件中樞為目的地端點類型時，事件方格一律會批次處理事件，以達最高效率和效能。 根據預設，傳遞至 Azure 事件中樞時，事件方格會處理批次行為，所以不提供批次原則設定。

批次原則

批次傳遞有兩個設定：

• 每個批次的事件數上限 - 事件方格每個批次傳遞的事件數目上限。 此值必須是 1 到 5,000 之間的整數。 這個數字永遠不會超過。 不過，如果傳遞時沒有更多事件可傳遞，可能會傳遞較少的事件。 如果事件較少，事件方格不會延遲事件來建立批次。
• 偏好的批次大小 (以 KB 為單位) - 以 KB 為單位的批次大小上限。 此值必須是 1 到 1024 之間的數字。 與事件數上限類似，如果傳遞時事件量不足，則批次大小可能會較小。 如果單一事件大於偏好的大小，批次可能會大於偏好的批次大小。 例如，如果慣用的大小是 4Kb，但推送至事件方格的事件為 10Kb，則 10Kb 事件仍會傳遞，而非予以卸除。

透過入口網站、CLI、PowerShell 或 SDK 依事件訂閱設定的批次傳遞。

批次行為

• 全部或無

  事件方格會以全部或無語意運作。 不支援部分成功的批次傳遞。 使用訂閱者時應該注意，只要求其每批次最多能在 30 秒內合理處理的事件。

• 開放式批次

  批次處理原則設定不是批次處理行為的嚴格界限，且會遵守最佳方式。 低事件率下常會發現批次大小小於每個批次所要求的事件上限。

• 預設值設定為 OFF

  根據預設，事件方格只會在每個傳遞要求中新增一個事件。 開啟批次處理的方式是設定批次原則所提及之兩項設定的其中一項。

• 預設值

  建立事件訂閱時，不需要同時指定兩項設定 (每批次的事件數目上限和大概的批次大小 (KB))。 如果只設定一項設定，事件方格會使用預設值。 請參閱下列各節以瞭解預設值，以及如何覆寫預設值。

Azure 入口網站

您可以在 [事件訂閱] 頁面的 [其他功能] 索引標籤中看到這些設定，或在建立事件訂閱後，於存取事件訂閱時於 [設定] 功能表選項中看到這些設定。

無效事件

當事件方格無法在某個時段內傳遞事件，或在嘗試一定次數之後仍無法傳遞事件，就會將該事件傳送至儲存體帳戶。 此程序稱為無效化。 符合下列其中一個條件時，事件方格就會將事件無效化。

• 事件未在存留時間內傳遞 (事件訂閱中定義的保留期)。
• 嘗試傳遞事件的次數已超過限制。

只要符合其中一項條件，事件就會予以卸除或變更為無效信件。 依預設，事件方格不會開啟無效化。 若要啟用，您必須在建立事件訂用帳戶時指定儲存體帳戶，以保留未傳遞的事件。 您可讀取此儲存體帳戶的事件，以解析傳遞項目。

事件方格在試過所有重試嘗試後，會將事件傳送至無效信件位置。 如果事件方格收到 400 (不正確的要求) 或 413 (要求實體太大) 回應碼，則會立即排程事件無效化。 這些回應碼指出永遠無法成功傳遞事件。

「只有」在下次排程的傳遞嘗試時，才會檢查存留時間到期。 因此，即使下一次排程傳遞嘗試之前存留時間到期，事件到期只會在下一次傳遞時進行檢查，然後接續已變更為無效信件。

最後一次嘗試傳遞事件以及傳遞至無效位置之間有五分鐘的延遲。 此延遲的目的是為了減少 Blob 儲存體的作業次數。 如果無法取得無效位置長達四小時，將會捨棄事件。

在開始設定無效位置之前，您必須先有儲存體帳戶及容器。 建立事件訂用帳戶時，您提供用於此容器的端點。 端點的格式如下：/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

您可以選擇在事件已傳送至無效信件位置時接收通知。 若要使用事件方格來回應未傳遞事件，請為無效信件 Blob 儲存體建立事件訂用帳戶。 每當您的無效信件 Blob 儲存體收到未傳遞事件時，事件方格就會通知您的處理常式。 處理常式會以您希望採取的動作來回應，以便協調未傳遞事件。

設定無效信件時，您必須在保存無效信件事件的 Azure 儲存體帳戶上，將受控識別新增至適當的角色型存取控制 (RBAC) 角色。 如需詳細資訊，請參閱支援的目的地和 Azure 角色。

傳遞事件格式

本節提供使用 CloudEvents 1.0 結構描述的事件和無效信件事件範例，這是命名空間主題中支援的訊息中繼資料格式。

CloudEvents 1.0 schema

Event

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

無效信件事件

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Probation

如果事件傳遞至該目的地開始失敗，則事件方格會將事件訂閱放入探查一段時間。 針對目的地端點所傳回的錯誤不同，探查時間就不同。 如果事件訂閱處於探查狀態，事件可能會收到無效信件或卸除，而不需要甚至根據錯誤碼進行探查而嘗試傳遞。

錯誤	探查持續時間
忙碌	10 秒
NotFound	5 分鐘
SocketError	30 秒
ResolutionError	5 分鐘
停用	5 分鐘
完整	5 分鐘
TimedOut	10 秒
未經授權	5 分鐘
禁止	5 分鐘
InvalidAzureFunctionDestination	10 分鐘

注意

事件方格會使用探查持續時間進行更好的傳遞管理，而且持續時間未來可能會變更。

訊息傳遞狀態

Event Grid 使用 HTTP 回應碼以確認接收事件。

成功碼

事件方格只會將下列 HTTP 回應碼視為成功的傳遞。 其他狀態碼都會視為失敗的傳遞，並視需要重試或變更為無效信件。 事件方格在收到成功的狀態碼後，才會考慮傳遞完成。

• 200 OK
• 201 Created
• 202 已接受
• 203 非授權資訊
• 204 無內容

失敗碼

上述集合中未包含的其他代碼 (200-204) 都會視為失敗，並視需要加以重試。 有些會繫結以下所述的特定重試原則，其他則全都遵循標準重試排程。 請記住，由於事件方格架構的高度平行本質，其重試行為不具確定性。

狀態碼	重試行為
400 不正確的要求	未重試
401 未經授權	5 分鐘以後重試 Azure 資源端點
403 禁止	未重試
404 找不到	5 分鐘以後重試 Azure 資源端點
408 要求逾時	2 分鐘以後重試
413 要求實體太大	未重試
503 服務無法使用	30 秒以後重試
All others	10 秒以後重試

自訂傳遞屬性

事件訂閱可讓您設定傳遞事件中包含的 HTTP 標頭。 這項功能可讓您設定目的地所需的自訂標頭。 建立事件訂閱時，最多可以設定 10 個標頭。 每個標頭值不應該大於 4,096 (4K) 個位元組。 您可以在傳遞至下列目的地的事件上設定自訂標頭：

• Webhooks
• Azure 事件中樞

下一步

• 將事件傳遞至 Webhook 端點。