你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用命名空间主题的消息推送传递和重试
事件网格命名空间推送传递可提供持久的传递。 事件网格会尝试为每个匹配的订阅至少立即传递每个消息一次。 如果订阅方的终结点没有确认收到事件或有故障发生,事件网格会根据固定的“重试计划”和“重试策略”重试传递。 默认情况下,事件网格一次向订阅方传递一个事件。
注意
事件网格不保证事件传送的顺序,因此订阅者可能会收到不按顺序的事件。
事件订阅
事件订阅是与单个命名空间主题关联的配置资源。 此外,可以使用事件订阅来设置事件选择条件,以便基于主题中的整个事件集定义订阅服务器可用的事件集合。 使用事件订阅,还可以定义事件要发送到的目标终结点。 此外,事件订阅支持设置其他属性,例如最大传递重试计数和事件生存时间,这定义了事件传递的运行时行为。
重试计划
当事件网格收到事件传递尝试的错误时,事件网格会根据错误类型确定是否应重试传递。
如果订阅的终结点返回的错误与配置相关,且无法通过重试修复,则事件网格会将事件发送到已配置的死信目标。 如果未配置死信,则会删除该事件。 例如,当无法访问事件订阅上配置的终结点时,事件会进入死信状态或删除,因为它已被删除。 出现以下条件和错误时不会发生传递重试:
条件:
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 分钟、15 分钟、20 分钟),但此时事件已成为死信。
输出批处理
使用 Webhook 作为目标终结点类型时,事件网格默认将每个事件单独发送到订阅者。 你可以将事件网格配置为批量处理要传送的事件,以在高吞吐量方案中提高 HTTP 性能。 默认情况下批处理处于关闭状态,但可以按每订阅启用。
使用事件中心作为目标终结点类型时,事件网格将始终批量处理事件,以实现最大的效率和性能。 没有可用的批处理策略配置,因为默认情况下,事件网格将会在向 Azure 事件中心传递时处理批处理行为。
批处理策略
批量传送有两个设置:
- 每批最大事件数 - 事件网格每批次可传递的最大事件数。 该值必须是介于 1 和 5,000 之间的整数。 此数字永远不会超过。 但如果在传递时没有更多事件可用,则可能会传递更少的事件。 如果只有较少的事件,事件网格不会为了创建某个批而延迟事件传送。
- 首选批大小(KB) - 批大小的目标上限 (KB)。 该值必须是介于 1 和 1024 之间的数字。 与最大事件数类似,如果传递时没有足够的事件可用,则批大小可能会较小。 如果单个事件大于首选大小,则批可能会大于首选批大小。 例如,如果首选大小为 4Kb,并将 10Kb 事件推送到事件网格,则会传递 10Kb 事件,而不是将其删除。
可以通过门户、CLI、PowerShell 或 SDK 以每事件订阅为基础配置批量传递。
批处理行为
全或无
事件网格使用“全或无”语义运行。 它不支持批处理传送部分成功。 订阅者应注意,每批只请求他们可在 30 秒内合理处理的事件数量。
乐观批处理
批处理策略设置对批处理行为的限制并不严格,应尽力遵守。 如果事件处理率较低,则会发现批大小小于每批请求的最大事件数。
默认设置为关闭
默认情况下,事件网格仅向每个传送请求添加一个事件。 启用批处理的方法是设置批处理策略中提到的任一设置。
默认值
创建事件订阅时,不必同时指定两个设置(每批最大事件数和近似批大小 [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 架构
事件
{
"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:试用
如果到目标的事件传递开始失败,则事件网格会将事件订阅置于试用状态。 对于目标终结点返回的不同错误,试用时间不同。 如果事件订阅正在试用期,事件可能会死信或被丢弃,而不会尝试传送,具体取决于导致其处于试用期的错误代码。
错误 | 试用持续时间 |
---|---|
忙碌 | 10 秒 |
NotFound | 5 分钟 |
SocketError | 30 秒 |
ResolutionError | 5 分钟 |
已禁用 | 5 分钟 |
完全 | 5 分钟 |
已超时 | 10 秒 |
未授权 | 5 分钟 |
禁止 | 5 分钟 |
InvalidAzureFunctionDestination | 10 分钟 |
注意
事件网格使用试用持续时间改进传送管理,将来的持续时间可能会改变。
消息传送状态
事件网格使用 HTTP 响应代码确认已接收事件。
成功代码
事件网格仅将以下 HTTP 响应代码视为传送成功。 所有其他状态代码被视为传递失败,并将相应地重试传递或将其设为死信。 当事件网格收到成功状态代码时,它认为发送完成。
- 200 正常
- 201 Created
- 202 已接受
- 203 非权威信息
- 204 无内容
失败代码
不在上述集合 (200-204) 内的所有其他代码会被视为失败,并将按需重试。 一些代码已关联到下面所述的特定重试策略,所有其他代码将遵循标准重试计划。 请务必注意,由于事件网格体系结构的高度并行化特性,重试行为是不确定的。
状态代码 | 重试行为 |
---|---|
400 错误的请求 | 不重试 |
401 未授权 | 在 5 分钟或更长时间后为 Azure 资源终结点进行重试 |
403 禁止访问 | 不重试 |
404 未找到 | 在 5 分钟或更长时间后为 Azure 资源终结点进行重试 |
408 请求超时 | 2 分钟或更长时间后重试 |
413 请求实体太大 | 不重试 |
503 服务不可用 | 30 秒或更长时间后重试 |
所有其他 | 10 秒或更长时间后重试 |
自定义传递属性
通过事件订阅,可以设置已传递事件中包含的 HTTP 头。 使用此功能,可设置目标所需的自定义标头。 创建事件订阅时,最多可以设置 10 个标头。 每个标头值不应大于 4096 (4K) 字节。 可以对传递到以下目标的事件设置自定义标头:
- Webhook
- Azure 事件中心