Azure 函数的 CosmosDB 触发器答案

【问题标题】：CosmosDB trigger for Azure functionsAzure 函数的 CosmosDB 触发器
【发布时间】：2021-02-20 08:45:42
【问题描述】：

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

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

【问题讨论】：

好奇为什么您暗示需要高级服务总线？为什么不使用标准？
遗憾的是，我工作的地方出于我不知道的原因强制要求这样做。

标签： azure-functions azure-cosmosdb cosmosdbtrigger

【解决方案1】：

The Azure Functions trigger for Cosmos DB uses the Change Feed Processor Library internally 在下面。关于其error handling 状态的文档：

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

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

【讨论】：

“Azure Functions 中的 Cosmos DB 触发器使用更改源处理器”你能引用源代码吗？
“Cosmos DB 的 Azure Functions 触发器在内部使用更改源处理器库”-docs.microsoft.com/en-us/azure/cosmos-db/…

【解决方案2】：

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

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

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

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

【讨论】：

【解决方案3】：

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

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

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

对于 C#，添加以下属性

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

【讨论】：