事件网格发送具有不同ID的重复事件

Question

我已经配置了事件网格订阅，以在创建资源时启动针对资源组中事件的Web挂接调用。

Web挂钩调用已成功处理，我返回200。为保持幂等性，我将发生的所有事件webhook_events与事件ID一起存储在表中。检查任何新事件，以查看它们是否存在于该表中。

这对我来说是个问题，因为我多次接收到同一事件，但ID却不同。我通过差异检查器将其发送，并确认事件之间的唯一区别是它们的eventTime和它们的ID（但这是同一事件，即SQL数据库上的Microsoft.Resources.ResourceWriteSuccess）。

原因是事件网格多次向我发送具有不同ID的同一事件吗？

编辑：

我已与Microsoft谈过此事，他们告诉我，如果未返回接受的响应代码，则该事件将使用不同的ID复制并再次发送。这显然是一个痛苦的工作。

我立即以200 OK响应，但是事件网格太大且处理起来太慢，无法接受我的事件，因此它再次发送了事件。我想挑战任何人，寻找一种区分这些重复事件的方法。

Answer 1

如果你查看文档，这就是 EventGrid 的实现方式

如果端点在 3 分钟内响应，事件网格将尽力尝试从重试队列中删除该事件，但仍可能收到重复事件。

您可以使用后端代码清理日志和存储的数据，使用事件和消息 ID 来识别重复项。

Answer 2

id 事实上，每个事件的字段都是唯一的，并且在重试之间保持相同，因此可用于重复数据删除。

您遇到的是 Azure 资源管理器 (ARM) 生成的某些事件的特定问题。具体来说，您看到的两个事件实际上是不同的事件，而不是重复事件，由 ARM 在某些资源类型的创意流程的不同阶段生成。

ARM 充当各种 Azure 服务的 API 前门，并发出一组通用事件，并且通常要获取所发生事件的详细信息，您需要查看数据负载。例如，ARM 将为从 Azure 服务接收到的每个 2xx 状态代码发出一个成功事件，因此接受 202 和创建 201 可能会导致发出两个事件，而查看差异的唯一方法是在数据负载中。

这是一个已知的痛点，我们正在努力发出更多高保真事件，这些事件在这些场景中将更清晰、更容易做出反应。理想的状态将是 Azure 控制平面的某种变更源。