Azure 事件网格重试失败答案

【问题标题】：Azure Event Grid failed retriesAzure 事件网格重试失败
【发布时间】：2018-01-26 17:27:23
【问题描述】：

Documentation on retries 表示在预定义的 2 小时重试周期（服务 GA 时为 24 小时）后，重试被捕获。未成功传递的事件会发生什么？有没有办法使用 Storage blob 之类的东西来存储它们？

【问题讨论】：

【解决方案1】：

我是 Azure 事件网格团队的一名 Microsoft 项目经理。文档是正确的，而在预览中，该服务将丢弃未在 2 小时内传递的消息。当我们普遍提供这项服务时（在键入此内容时尚未确定日期），或者甚至在我们将此时间增加到 24 小时之前。在 Blob Storage 中存储消息的想法是我们在使该服务普遍可用之前强烈考虑的事情。

【讨论】：

谢谢贾斯汀。所以这将是我认为的功能请求。我在哪里可以提高它？也许是 GitHub 存储库？ ?
@SeanFeldman 我们还没有用于 Event Grid 的公共 GitHub 存储库，但我会确保我们在内部跟踪此功能请求。
只是一个建议：只能有一个带有问题跟踪器的回购。内部跟踪很好，但回购更安全?

【解决方案2】：

自Azure EventGrid 以来的更新现已正式发布：

来自文档 (Event Grid message delivery and retry)：

事件网格使用指数退避重试策略进行事件传递。

事件网格为所有重试步骤添加了一个小的随机化。一小时后，每小时重试一次事件传递。

默认情况下，事件网格会使所有未在 24 小时内交付的事件过期。您可以在创建事件订阅时自定义重试策略。您提供最大传递尝试次数（默认为 30）和事件生存时间（默认为 1440 分钟）。

当事件网格无法传递事件时，它可以将未传递的事件发送到存储帐户。这个过程被称为死信。默认情况下，事件网格不会打开死信。要启用它，您必须在创建事件订阅时指定一个存储帐户来保存未传递的事件。您从此存储帐户中提取事件以解决交付问题。

有关设置死信位置的示例，请参阅Dead letter and retry policies。

【讨论】：