azure - 存储和事件网格之间的弹性

Question

这是我的导入流程:

• 当在 Blob 存储上检测到新文件并且事件被触发到事件网格时
• 事件网格重试，直到他能够调用 Azure 函数
• Azure Function 将事件注入(inject)服务总线的队列
• 网络应用程序将消耗队列

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

Answer 1

... So I guess that this process is very resilient because each message is stored or retried. The only step that could fail is the connection between the storage and the event grid. What if the connection between the Storage and the event grid is down when a file is created on the storage. How can I be sure that the event will still be triggered?

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

There is no service level agreement (SLA) for server-side disaster recovery. If the paired region has no extra capacity to take on the additional traffic, Event Grid cannot initiate failover. Service level objectives are best-effort only.

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

恢复点目标 (RPO)

• 元数据 RPO:零分钟。每当在事件网格中创建资源时，它都会立即跨区域复制。发生故障转移时，不会丢失任何元数据。
• 数据 RPO:如果您的系统运行状况良好并且在区域故障转移时能够满足现有流量的需求，则事件的 RPO 约为 5 分钟。

恢复时间目标 (RTO)

• 元数据 RTO:虽然通常发生得更快，但在 60 分钟内，事件网格将开始接受主题和订阅的创建/更新/删除调用。
• 数据 RTO:与元数据一样，它通常发生得更快，但在 60 分钟内，事件网格将在区域故障转移后开始接受新流量。

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