Google的发布/订阅服务为消息的订阅者提供了一个端点，以明确确认消息的成功传递。如果未使用此端点，则订阅者必须在超时之前返回 200 响应，否则 pub/sub 会认为消息传递不成功，并将在超时后重试发送。 因此，对于长时间运行的订阅者进程，可以在运行主进程之前先发送确认，而不是等到进程完成。
我无法在 Azure 事件网格中找到类似的机制，因此，如果事件处理程序花费很长时间(根据文档，超时仅为 30 秒(，则在过程中，事件网格会重试向同一订阅者发送更多事件：
"事件网格在传递消息后等待 30 秒的响应。30 秒后，如果终结点未响应，则消息将排队等待重试。事件网格使用指数退避重试策略进行事件传递。
在事件网格中确认成功接收事件真的没有一种显式方法吗？ 我在 EventGridClient 中找到了一个名为 LongRunningOperationRetryTimeout 的属性，但是将此属性设置为较大的值将延迟实际需要的重试。
我知道我可以使用其他机制，例如存储队列或持久函数，但我希望在修改代码之前查看事件网格的可用选项。
事件网格不确认事件传递。从发布者的角度来看，这并不重要，因为发布者和订阅者之间不应该有耦合。如果订阅者不可用或无法接收事件，事件网格将重试。如果消息无法传递，则可以配置死信队列。
另一种方法是使用队列(服务总线或队列存储(或主题(服务总线(作为处理程序。这样，事件就会转发给订阅者，并保证传递消息。请参阅作为处理程序的服务总线和作为处理程序的队列存储。