我已经配置了事件网格订阅，以便在创建资源时针对资源组中的事件启动Web挂钩调用。
成功完成了Web挂钩调用，并且返回200。为保持幂等性，我将所有发生过的事件存储在带有事件ID的Web挂钩表中，并检查所有传入事件以查看它们是否存在桌子。
这对我来说是个问题，因为我多次收到具有不同ID的同一事件。我通过差异检查器将其发送，并确认事件之间的唯一区别是它们的eventTime和其id（但这是同一事件，即SQL数据库上的Microsoft.Resources.ResourceWriteSuccess）。
事件网格有没有多次向我发送具有相同ID的同一事件的原因？
答案 0 :(得分：4)
如果您查看documentation
，这就是EventGrid的实现方式如果端点在3分钟内响应，事件网格将尝试 尽最大努力从重试队列中删除事件，但 仍可能会收到重复的邮件。
您可以使用后端代码来清理日志和存储的数据，并使用事件和消息ID来识别重复项。
答案 1 :(得分：1)
id field实际上在每个事件中都是唯一的，并且在重试之间保持相同，因此可以用于重复数据删除。
您遇到的是与Azure资源管理器（ARM）生成的某些事件有关的特定问题。具体来说，您看到的两个事件实际上是ARM在某些资源类型的广告素材流程的不同阶段生成的不同事件，而不是重复事件。
ARM充当各种Azure服务的API前门，并发出a set of events的通用信息，通常要获取已发生事件的详细信息，您需要查看数据有效负载。例如，ARM将针对从Azure服务接收到的每个2xx状态代码发出一个成功事件，因此接受202和创建201可能导致发出两个事件，而唯一的区别在于数据有效负载
这是一个已知的痛点，我们正在努力发出更多高保真事件，这些事件在这些情况下将变得更清晰，更容易做出反应。理想状态将是Azure控制平面的各种变更馈送。