Event Grid 訊息傳遞與重試
事件方格提供持久傳遞。 其會嘗試為每個相符的訂閱立即傳遞每則訊息至少一次。 如果訂閱者的端點未確認收到事件,或如果發生失敗,事件方格會根據固定重試排程和重試原則重試傳遞。 依預設,[事件方格] 一次會將一個事件傳遞給訂閱者。 不過,承載為具有單一事件的陣列。
注意
事件方格不保證事件傳遞的順序,因此訂閱者可能不會依序收到事件。
重試排程
當事件方格收到事件傳遞嘗試的錯誤時,EventGrid 會根據錯誤的類型決定要重試傳遞、使事件無效化或捨棄事件。
例如,如果訂閱端點所傳回的錯誤為無法透過重試來修正的組態相關錯誤 (例如,如果已將端點刪除),事件方格就會在事件上執行無效信件處理,如果未設定無效信件,則卸除事件。
下表描述不會發生重試的端點和錯誤類型:
端點類型 | 錯誤碼 |
---|---|
Azure 資源 | 400 (不正確的要求),413 (要求實體太大) |
Webhook | 400 (不正確的要求),413 (要求實體太大),401 (未經授權) |
注意
針對端點,如果未設定「無效信件」,當發生上述錯誤時,就會卸除事件。 如果不想卸除這類事件,請考慮設定「無效信件」。 找不到無效信件目的地時,將會卸除無效信件事件。
如果訂閱端點傳回的錯誤不在上述清單中,事件方格會使用下列原則來執行重試:
事件方格在傳遞訊息後,等候回應為 30 秒。 30 秒之後,如果端點未回應,訊息會排入重試佇列。 事件方格使用指數輪詢重試原則進行事件傳遞。 事件方格會以最佳方式重試下列排程的傳遞:
- 10 秒
- 30 秒
- 1 分鐘
- 5 分鐘
- 10 分鐘
- 30 分鐘
- 1 小時
- 3 小時
- 6 小時
- 每 12 小時最多 24 小時
如果端點在 3 分鐘內回應,Azure 事件方格會嘗試以最佳方式從重試佇列中移除事件,但可能還是會收到重複項目。
事件方格會將小型隨機化新增至所有重試步驟,而且如果端點持續狀況不良、長時間無法運作或似乎超載,可能會略過特定重試。
重試原則
建立事件訂閱時,您可以使用下列兩個組態來自訂重試原則。 如果達到重試原則的任一限制,就會捨棄事件。
- 嘗試次數上限 - 此值必須是介於 1 到 30 之間的整數。 預設值是 30。
- 事件存留時間 (TTL) - 此值必須是介於 1 到 1440 之間的整數。 預設值為 1440 分鐘
如需樣本 CLI 和 PowerShell 命令來設定這些設定,請參閱設定重試原則。
注意
如果您同時設定 Event time to live (TTL)
和 Maximum number of attempts
,事件方格就會使用前者作為到期條件,來判斷何時停止事件傳遞。 例如,如果您將 30 分鐘設定為存留時間 (TTL) 和 5 次傳遞嘗試上限。 當事件在 30 分鐘後未傳遞 (或) 在 5 次嘗試之後無法傳遞,無論是否為首次發生,事件均為無效信件。 如果您將最大傳遞嘗試設定為 10,相對於 指數重試排程,將會達到 30 分鐘 TTL 之前的最多 6 次傳遞嘗試次數,因此將嘗試次數上限設定為 10 將不會影響此案例,且事件會在 30 分鐘後寄不出。
輸出批次
事件方格預設會個別將每個事件傳送至訂閱者。 訂閱者會收到包含單一事件的陣列。 您可以將事件方格設定為批次傳遞事件,以改善高輸送量案例中的 HTTP 效能。 批次預設為關閉,而且可以依訂閱個別開啟。
批次原則
批次傳遞有兩個設定:
- 每個批次的事件數上限 - 事件方格每個批次傳遞的事件數目上限。 這個數目絕對不會超過,但如果發佈時沒有其他事件可用,不管多麼少的事件都可能會傳遞。 如果事件較少,事件方格不會延遲事件來建立批次。 必須介於 1 到 5,000 之間。
- 偏好的批次大小 (以 KB 為單位) - 以 KB 為單位的批次大小上限。 與事件數上限類似,如果發佈時沒有更多事件,批次大小可能會較小。 如果單一事件大於偏好的大小,批次可能會大於偏好的批次大小。 例如,如果偏好的大小為 4 KB,而推送至 Event Grid 的事件大小為 10 KB,則 10 KB 的事件仍會在其批次中傳遞,而不會遭到捨棄。
透過入口網站、CLI、PowerShell 或 SDK,以個別事件訂閱為基礎設定的批次傳遞。
批次行為
全部或無
事件方格會以全部或無語意運作。 不支援部分成功的批次傳遞。 使用訂閱者時應該注意,只要求其每批次最多能在 30 秒內合理處理的事件。
開放式批次
批次處理原則設定不是批次處理行為的嚴格界限,且會遵守最佳方式。 在低事件速率下,您通常會發現批次大小小於每個批次所要求的事件上限。
預設值設定為 OFF
根據預設,事件方格只會在每個傳遞要求中新增一個事件。 若要開啟批次,需設定事件訂閱 JSON 文章前述內容中的任一設定。
預設值
建立事件訂閱時,不需要同時設定每個批次的事件數目上限,以及大概的批次大小 (KB)。 如果只設定其中之一,事件方格會使用可設定的預設值。 請參閱下列各節以瞭解預設值,以及如何覆寫預設值。
Azure 入口網站︰
您可以在 [事件訂閱] 頁面上的 [其他功能] 索引標籤上看到這些設定。
Azure CLI
建立事件訂閱時,請使用下列參數:
- max-events-per-batch - 批次中的事件數目上限。 必須為介於 1 到 5000 的數字。
- preferred-batch-size-in-KB - 以 KB 為單位的慣用批次大小。 必須為介於 1 到 1024 的數字。
storageid=$(az storage account show --name <storage_account_name> --resource-group <resource_group_name> --query id --output tsv)
endpoint=https://$sitename.azurewebsites.net/api/updates
az eventgrid event-subscription create \
--resource-id $storageid \
--name <event_subscription_name> \
--endpoint $endpoint \
--max-events-per-batch 1000 \
--preferred-batch-size-in-kilobytes 512
如需搭配事件方格使用 Azure CLI 的詳細資訊,請參閱 使用 Azure CLI 將儲存體事件路由傳送至 Web 端點。
延遲傳遞
當端點遇到傳遞失敗時,事件方格即開始延遲傳遞,並重試傳遞事件至該端點。 例如,如果發行至端點的前 10 個事件失敗,事件方格會假設端點發生問題,而且會延遲所有後續的重試和新的傳遞一段時間,在某些情況下最多數小時。
延遲傳遞的功能性目的是保護狀況不良的端點和事件方格系統。 如果不停止並延遲傳遞至狀況不良的端點,事件方格的重試原則和磁碟區功能可能很容易讓系統負荷過大。
無效事件
當事件方格無法在特定一段時間內傳遞事件,或在經過特定嘗試次數後仍無法傳遞事件時,可以將未傳遞的事件傳送至儲存體帳戶。 此程序稱為無效化。 符合下列其中一個條件時,事件方格就會將事件無效化。
- 無法在存留時間內傳遞事件。
- 嘗試傳遞事件的次數已超過限制。
如果符合任一條件,事件就會遭到捨棄或無效化。 依預設,事件方格不會開啟無效化。 若要啟用,您必須在建立事件訂用帳戶時指定儲存體帳戶,以保留未傳遞的事件。 您從此儲存體帳戶提取事件以解析傳遞。
事件方格在試過所有重試嘗試後,會將事件傳送至無效信件位置。 如果事件方格收到 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 結構描述,以及自訂結構描述)。 如需這些格式的詳細資訊,請參閱 事件方格結構描述 和 雲端事件 1.0 結構描述 文章。
事件方格結構描述
Event
{
"id": "93902694-901e-008f-6f95-7153a806873c",
"eventTime": "2020-08-13T17:18:13.1647262Z",
"eventType": "Microsoft.Storage.BlobCreated",
"dataVersion": "",
"metadataVersion": "1",
"topic": "/subscriptions/000000000-0000-0000-0000-00000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
"subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",
"data": {
"api": "PutBlob",
"clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
"requestId": "93902694-901e-008f-6f95-7153a8000000",
"eTag": "0x8D83FACDC0C3402",
"contentType": "text/plain",
"contentLength": 0,
"blobType": "BlockBlob",
"url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
"sequencer": "00000000000000000000000000015508000000000005101c",
"storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
}
}
無效信件事件
{
"id": "93902694-901e-008f-6f95-7153a806873c",
"eventTime": "2020-08-13T17:18:13.1647262Z",
"eventType": "Microsoft.Storage.BlobCreated",
"dataVersion": "",
"metadataVersion": "1",
"topic": "/subscriptions/0000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.Storage/storageAccounts/myegteststgfoo",
"subject": "/blobServices/default/containers/deadletter/blobs/myBlobFile.txt",
"data": {
"api": "PutBlob",
"clientRequestId": "c0d879ad-88c8-4bbe-8774-d65888dc2038",
"requestId": "93902694-901e-008f-6f95-7153a8000000",
"eTag": "0x8D83FACDC0C3402",
"contentType": "text/plain",
"contentLength": 0,
"blobType": "BlockBlob",
"url": "https://myegteststgfoo.blob.core.windows.net/deadletter/myBlobFile.txt",
"sequencer": "00000000000000000000000000015508000000000005101c",
"storageDiagnostics": { "batchId": "cfb32f79-3006-0010-0095-711faa000000" }
},
"deadLetterReason": "MaxDeliveryAttemptsExceeded",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "NotFound",
"publishTime": "2020-08-13T17:18:14.0265758Z",
"lastDeliveryAttemptTime": "2020-08-13T17:18:14.0465788Z"
}
以下為lastDeliveryOutcome
的可能值及其描述。
LastDeliveryOutcome | 描述 |
---|---|
NotFound | 目的地資源找不到。 |
停用 | 目的地已停用接收事件。 適用於 Azure 服務匯流排和 Azure 事件中樞。 |
完整 | 超過目的地允許的作業數目上限。 適用於 Azure 服務匯流排和 Azure 事件中樞。 |
未經授權 | 目的地傳回未經授權的回應碼。 |
BadRequest | 目的地傳回不正確的要求回應碼。 |
TimedOut | 傳遞作業逾時。 |
忙碌 | 目的地伺服器忙碌中。 |
PayloadTooLarge | 訊息大小超過目的地允許的大小上限。 適用於 Azure 服務匯流排和 Azure 事件中樞。 |
探查 | 目的地會依事件方格放入探查。 探查期間不會嘗試傳遞。 |
已取消 | 傳遞作業已取消。 |
已中止 | 事件方格在時間間隔後中止傳遞。 |
SocketError | 傳遞期間發生網路通訊錯誤。 |
ResolutionError | 目的地端點 DNS 解析失敗。 |
傳遞 | 將事件傳遞至目的地。 |
SessionQueueNotSupported | 未嘗試在已啟用工作階段支援的實體上傳遞工作階段識別碼的事件傳遞。 適用於 Azure 服務匯流排實體目的地。 |
禁止 | 目的地端點禁止傳遞 (可能因為 IP 防火牆或其他限制) |
InvalidAzureFunctionDestination | 目的地 Azure 函式無效。 可能因為其沒有 EventGridTrigger 類型。 |
LastDeliveryOutcome: Probation
如果事件傳遞至該目的地開始失敗,事件訂閱就會透過事件方格持續進入探查時間。 針對目的地端點所傳回的錯誤不同,探查時間就不同。 如果事件訂閱處於探查狀態,事件可能會收到無效信件或卸除,而甚至不需要根據錯誤碼 (因而受到探查) 而嘗試傳遞。
錯誤 | 探查持續時間 |
---|---|
忙碌 | 10 秒 |
NotFound | 5 分鐘 |
SocketError | 30 秒 |
ResolutionError | 5 分鐘 |
停用 | 5 分鐘 |
完整 | 5 分鐘 |
TimedOut | 10 秒 |
未經授權 | 5 分鐘 |
禁止 | 5 分鐘 |
InvalidAzureFunctionDestination | 10 分鐘 |
注意
事件方格會使用探查持續時間進行更好的傳遞管理,而且持續時間未來可能會變更。
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
}
}
無效信件事件
{
"id": "caee971c-3ca0-4254-8f99-1395b394588e",
"source": "mysource",
"dataversion": "1.0",
"subject": "mySubject",
"type": "fooEventType",
"datacontenttype": "application/json",
"data": {
"prop1": "value1",
"prop2": 5
},
"deadletterreason": "MaxDeliveryAttemptsExceeded",
"deliveryattempts": 1,
"lastdeliveryoutcome": "NotFound",
"publishtime": "2020-08-13T21:21:36.4018726Z",
}
自訂結構描述
Event
{
"prop1": "my property",
"prop2": 5,
"myEventType": "fooEventType"
}
無效信件事件
{
"id": "8bc07e6f-0885-4729-90e4-7c3f052bd754",
"eventTime": "2020-08-13T18:11:29.4121391Z",
"eventType": "myEventType",
"dataVersion": "1.0",
"metadataVersion": "1",
"topic": "/subscriptions/00000000000-0000-0000-0000-000000000000000/resourceGroups/rgwithoutpolicy/providers/Microsoft.EventGrid/topics/myCustomSchemaTopic",
"subject": "subjectDefault",
"deadLetterReason": "MaxDeliveryAttemptsExceeded",
"deliveryAttempts": 1,
"lastDeliveryOutcome": "NotFound",
"publishTime": "2020-08-13T18:11:29.4121391Z",
"lastDeliveryAttemptTime": "2020-08-13T18:11:29.4277644Z",
"data": {
"prop1": "my property",
"prop2": 5,
"myEventType": "fooEventType"
}
}
訊息傳遞狀態
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 服務匯流排主題和佇列
- Azure 事件中樞
- 轉送混合式連線
如需詳細資訊,請參閱自訂傳遞屬性。
下一步
- 若要檢視事件傳遞的狀態,請參閱監視 Event Grid 訊息傳遞。
- 若要自訂事件傳遞選項,請參閱無效信件和重試原則。