我已将 EventGrid 订阅配置为在创建资源时为资源组中的事件启动 Web 挂钩调用。
成功处理了网络挂钩调用，我返回 200 OK。为了保持幂等性，我将所有发生的事件webhook_events与事件的 一起存储在一个表中id。任何新事件都会被检查以查看它们是否存在于该表中id。
Azure EventGrid 在返回 200 OK 后尝试从重试队列中删除事件。无论我以 200 OK 响应的速度有多快，EventGrid 都会可靠地重试发送。
我多次收到相同的事件（正如我所说，EventGrid 总是重试，因为它不能足够快地从重试队列中删除事件）。然而，这不是我问题的重点；相反，问题在于这些重试中的每一次都为我提供了不同id的事件。这意味着我无法从逻辑上确定事件的唯一性，并且我的应用程序代码没有以幂等方式执行。
尽管事件重试之间没有唯一标识符，我如何在我的应用程序和 Azure 之间保持幂等性？
如果端点在 3 分钟内做出响应，事件网格将尽最大努力尝试从重试队列中删除事件，但仍可能收到重复的事件。
您可以使用后端代码清理日志和存储的数据，使用事件和消息 ID 来识别重复项。
实际上，该id 字段对于每个事件都是唯一的，并且在重试之间保持相同，因此可用于重复数据删除。
您遇到的是 Azure 资源管理器 (ARM) 生成的某些事件的特定问题。具体来说，您看到的两个事件实际上是不同的事件，而不是重复事件，由 ARM 在某些资源类型的创意流程的不同阶段生成。
ARM 充当各种 Azure 服务的 API 前门，并为此发出一组通用事件，并且通常要获取已发生事件的详细信息，您需要查看数据有效负载。例如，ARM 将为它从 Azure 服务接收到的每个 2xx 状态代码发出一个成功事件，因此接受 202 和创建 201 可能导致发出两个事件，而查看差异的唯一方法是在数据有效负载中.
这是一个已知的痛点，我们正在努力发出更多的高保真事件，这些事件将在这些场景中更清晰、更容易做出反应。理想状态将是 Azure 控制平面的各种更改馈送。