存储和事件网格之间的弹性答案

【问题标题】：Resilience between the storage and the Event Grid存储和事件网格之间的弹性
【发布时间】：2022-01-17 00:19:58
【问题描述】：

这是我的导入流程：

所以我猜这个过程非常有弹性，因为每条消息都会被存储或重试。唯一可能失败的步骤是存储和事件网格之间的连接。如果在存储上创建文件时存储和事件网格之间的连接断开怎么办。如何确定该事件仍将被触发？

【问题讨论】：

为什么不让事件网格直接创建队列项？
@404 您仍然遇到同样的问题，即事件网格可能无法对 blob 存储更改做出反应。
@PeterBons 不错，但如果您在事件订阅中设置适当的重试策略，这不太可能发生。它还严重限制了 OP 帖子中的故障点。
@404 在我看来，OP 质疑存储帐户能够发送事件的可靠性，这是订阅控制之外的。这不是 OP 担心的消耗部分，因为确实有重试策略。
根据文档“存储事件保证至少向订阅者交付一次，从而确保输出所有消息”，因此 Microsoft 提供了弹性。您的其他弹性技术将在存储已交付给事件网格后处理错误。 docs.microsoft.com/en-us/azure/storage/blobs/…

【解决方案1】：

...所以我猜这个过程非常有弹性，因为每条消息都会被存储或重试。唯一可能失败的步骤是存储和事件网格之间的连接。如果在存储上创建文件时存储和事件网格之间的连接断开怎么办。 如何确定该事件仍会被触发？

你不能。虽然它是一个至少一次交付系统，但在内部它有适当的机制。 Blob 存储是一种支持系统主题的 Azure 服务，它不在您的控制范围内。不过，可能会出现影响服务的中断。服务器端灾难恢复没有服务级别协议（这是我们在这种情况下所处理的）：

没有用于服务器端灾难恢复的服务级别协议 (SLA)。如果配对区域没有额外容量来承担额外流量，则事件网格无法启动故障转移。服务水平目标只是尽力而为。

您可以找到恢复点目标online：

恢复点目标 (RPO)

恢复时间目标 (RTO)

因此，数据丢失的可能性极小，但没有 100% 的保证。你现在应该担心吗？可能不是因为机会非常低。

【讨论】：