1

我的问题是关于函数的 cosmosDB 触发器。我们正在探索触发我们功能的最佳方式。我们最初的想法是通过将消息推送到服务总线来触发它，并让函数从服务总线触发器中实例化。我们知道，当我们通过服务总线或队列触发一个函数时，如果函数执行由于某种原因失败，消息会在锁定期到期后返回队列中。这适合我们的用例，但高级服务巴士相当昂贵（600 美元 pm）。

我想知道当我们使用 CosmosDB 触发器时会发生什么？在这种情况下，如果函数失败（假设在未处理的异常期间），触发器是否丢失或者是否有某种方法来管理重新触发？我们如何管理重试和失败场景？

4

3 回答 3

2

Cosmos DB 的 Azure Functions 触发器在内部使用更改源处理器库。关于其错误处理状态的文档：

为了防止您的更改馈送处理器“卡住”不断重试同一批次的更改，您应该在委托代码中添加逻辑，以便在出现异常时将文档写入死信队列。这种设计确保您可以跟踪未处理的更改，同时仍然能够继续处理未来的更改。死信队列可能是另一个 Cosmos 容器。确切的数据存储无关紧要，只需保留未处理的更改即可。

要点是更改提要本身不会保留任何有关处理错误的状态——这取决于您作为消费者。更好的模式是将其与服务总线之类的队列配对，该队列为可靠的错误处理提供死信。一种模式是有一个专门的函数来读取 Cosmos 更改提要（使用 Cosmos 触发器），该函数只需将有趣的事件插入队列以触发其他函数进行可靠处理。

于 2021-02-20T15:19:45.367 回答
1

虽然更改提要触发器确实使用下面的更改提要处理器，但错误处理是不同的。

如果出现未处理的异常，更改馈送处理器将再次重试同一批次的文档。

另一方面，更改源触发器（类似于事件中心等其他触发器）继续处理未处理的异常（参考https://docs.microsoft.com/en-us/azure/cosmos-db/troubleshoot-changefeed-functions#some-我的触发器中缺少更改）。理想情况下，从代码的角度来看，请确保按照参考中的建议使用 try/catch 块来处理任何失败情况。

通常，失败的文档可以发送到队列或日志接收器以供以后分析。如果发送到死信队列，您可以使用 QueueTrigger 重试或任何其他机制，具体取决于故障的性质。

于 2021-02-22T17:10:22.240 回答
0

我认为作为标准，它不会重试，但目前有一个重试策略的预览功能，可用于所有触发器和语言。

例如，对于除 C# 之外的所有语言，将其添加到 function.json

    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 3,
        "delayInterval": "00:00:05"
    }

并为 C# 添加以下属性

[FixedDelayRetry(3, "00:00:05")]

有关配置的更多信息：https ://docs.microsoft.com/sv-se/azure/azure-functions/functions-bindings-error-pages?tabs=csharp#retry-policies-preview

于 2021-02-20T11:02:24.520 回答