你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

设置死信位置和重试策略

创建事件订阅时,可以自定义每个事件传递的设置。 本文介绍如何设置死信位置和自定义重试设置。 有关这些功能的信息,请参阅事件网格消息传送和重试

注意

若要了解消息传送、重试和死信,请参阅概念文章:事件网格消息传送和重试

设置死信位置

若要设置死信位置,需要一个存储帐户来保存无法传递到终结点的事件。 这些示例获取现有存储帐户的资源 ID。 它们创建一个事件订阅,该事件订阅使用该存储帐户中的容器作为死信终结点。

注意

  • 在本文中,在运行命令之前,请在存储中创建一个存储帐户和一个 blob 容器。
  • 事件网格服务会在此容器中创建 blob。 blob 的名称将包含事件网格订阅的名称,其中所有字母均为大写。 例如,如果订阅的名称为 My-Blob-Subscription,则死信 blob 的名称为 MY-BLOB-SUBSCRIPTION (myblobcontainer/MY-BLOB-SUBSCRIPTION/2019/8/8/5/111111111-1111-1111-1111-111111111111.json)。 此行为是为了防止 Azure 服务之间在大小写处理方面的差异。
  • 在上面的示例中,.../2019/8/8/5/... 表示填充的非零日期和小时 (UTC):.../YYYY/MM/DD/HH/...。`
  • 创建的死信 blob 将在数组中包含一个或多个事件,这是处理死信时需要考虑的重要行为。

Azure 门户

创建事件订阅时,可以在“其他功能”选项卡上启用死信,如下图所示。 启用该功能后,请指定将保存死信事件的 Blob 容器和具有 Blob 存储的 Azure 订阅。

可以选择为死信启用系统分配或用户分配的托管标识。 托管标识必须是允许将事件写入存储的基于角色的访问控制 (RBAC) 角色的成员。

显示事件订阅的死信配置的屏幕截图。

还可以启用死信并配置现有事件订阅的设置。 在事件订阅的“事件订阅”页上,切换到“其他功能”选项卡以查看死信设置,如下图所示。

显示现有事件订阅的死信配置的屏幕截图。

Azure CLI

containername=testcontainer

topicid=$(az eventgrid topic show --name demoTopic -g gridResourceGroup --query id --output tsv)
storageid=$(az storage account show --name demoStorage --resource-group gridResourceGroup --query id --output tsv)

az eventgrid event-subscription create \
  --source-resource-id $topicid \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --deadletter-endpoint $storageid/blobServices/default/containers/$containername

若要禁用死信,请重新运行命令以创建事件订阅,但不要为 deadletter-endpoint 提供值。 不需要删除事件订阅。

注意

如果是在本地计算机上使用 Azure CLI,请使用 Azure CLI 2.0.56 或更高版本。 有关安装 Azure CLI 的最新版本的说明,请参阅安装 Azure CLI

PowerShell

$containername = "testcontainer"

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id
$storageid = (Get-AzStorageAccount -ResourceGroupName gridResourceGroup -Name demostorage).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -DeadLetterEndpoint "$storageid/blobServices/default/containers/$containername"

若要禁用死信,请重新运行命令以创建事件订阅,但不要为 DeadLetterEndpoint 提供值。 不需要删除事件订阅。

注意

如果是在本地计算机上使用 Azure Poweshell,请使用 Azure PowerShell 1.1.0 或更高版本。 从 Azure 下载来下载并安装最新的 Azure PowerShell。

设置重试策略

创建事件网格订阅时,可以设置事件网格尝试使用多长时间来传递事件。 默认情况下,事件网格会尝试使用 24 小时(1440 分钟)或 30 次。 可以为你的事件网格订阅设置这些值之一。 事件生存时间的值必须是 1 到 1440 之间的整数。 最大重试次数的值必须是 1 到 30 之间的整数。

无法配置重试计划

Azure 门户

创建事件订阅时,可以在“其他功能”选项卡上配置重试策略设置。

显示事件订阅的重试策略配置的屏幕截图。

还可以为现有事件订阅配置重试策略设置。 在事件订阅的“事件订阅”页上,切换到“其他功能”选项卡以查看重试策略设置,如下图所示。

显示现有事件订阅的重试策略配置的屏幕截图。

Azure CLI

若要将事件生存期设置为 1440 分钟之外的值,请使用以下命令:

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --event-ttl 720

若要将最大重试次数设置为 30 之外的值,请使用以下命令:

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --max-delivery-attempts 18

注意

如果同时设置 event-ttlmax-deliver-attempts,则事件网格使用先到期的项来确定何时停止事件传递。 例如,如果将“生存时间(TTL)”设置为 30 分钟,将最大传递尝试次数设置为 5。 如果事件在 30 分钟后未传递或在 5 次尝试后未传递(以先发生的为准),则会将该事件视为死信事件。 如果将最大传递尝试数设置为 10,则对于 指数重试计划,在达到 30 分钟 TTL 之前将会进行最多 6 次传递尝试,因此在本案例中,将最大尝试次数设置为 10 没有影响,并且会在 30 分钟后对事件进行死信处理。

PowerShell

若要将事件生存期设置为 1440 分钟之外的值,请使用以下命令:

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -EventTtl 720

若要将最大重试次数设置为 30 之外的值,请使用以下命令:

$topicid = (Get-AzEventGridTopic -ResourceGroupName gridResourceGroup -Name demoTopic).Id

New-AzEventGridSubscription `
  -ResourceId $topicid `
  -EventSubscriptionName <event_subscription_name> `
  -Endpoint <endpoint_URL> `
  -MaxDeliveryAttempt 18

注意

如果同时设置 event-ttlmax-deliver-attempts,则事件网格使用先到期的项来确定何时停止事件传递。 例如,如果将“生存时间(TTL)”设置为 30 分钟,将最大传递尝试次数设置为 5。 如果事件在 30 分钟后未传递或在 5 次尝试后未传递(以先发生的为准),则会将该事件视为死信事件。 如果将最大传递尝试数设置为 10,则对于 指数重试计划,在达到 30 分钟 TTL 之前将会进行最多 6 次传递尝试,因此在本案例中,将最大尝试次数设置为 10 没有影响,并且会在 30 分钟后对事件进行死信处理。

后续步骤