如何在 Azure Cosmos DB 中重新触发 CosmosDBTrigger 事件或在处理事件时发生异常时获取触发事件答案

【问题标题】：How to re-trigger CosmosDBTrigger events in Azure Cosmos DB or get triggered event if there is an exception while processing the event如何在 Azure Cosmos DB 中重新触发 CosmosDBTrigger 事件或在处理事件时发生异常时获取触发事件
【发布时间】：2018-02-14 07:03:10
【问题描述】：

我已经使用 Cosmo DB 中的 Azure 函数配置了 CosmosDBTrigger，但是一旦触发事件，根据我的基本理解，它就会丢失，但是有什么方法可以存储触发事件，直到我的业务逻辑处理该事件。我已经阅读了有关租赁收集的信息，但有关租赁收集的许多详细信息并未在 Trigger 的上下文中给出。

有人可以像我们在 MQ 中那样帮助我存储触发器吗？

【问题讨论】：

你的意思是你想重试一个失败的函数。您还提到了如何。您使用队列。 MQ 不是代码执行服务，它是一个将消息推送到其他服务执行的队列。如果该服务没有使用消息，则会重试
将消息发布到 Azure 队列，如果 Azure 函数成功，则将其删除。如果没有，则消息将在其租用时间到期后自行重新出现在队列中

标签： azure azure-cosmosdb azure-functions

【解决方案1】：

Lease 集合用于存储有关触发器当前所在更改源中位置的检查点，并帮助在触发器的多个实例之间分配负载。

如果您拥有 Trigger 的 Azure Function 不等待业务层完成处理，您可以使用 EventHub、Service Bus 或 Storage Queue 来维护批处理标识符和跟踪状态。

触发器向函数发送IReadOnlyList<Document>，函数基本上是一个文档列表。您可以将其序列化到队列消息，添加与您的业务逻辑流程相关的标识符，然后让另一个触发器（绑定到队列或 EventHub 或服务总线）接收消息，根据业务检查批次的状态逻辑并在需要时重试，如果完成则更新状态。

我认为重点是避免瓶颈，如果触发器（来自您的收集活动）拾取的更改量很快但您的业务逻辑速度较低，则中间队列可能会以更快的速度增长速率超出您的处理能力，但这取决于您的数据和场景的节奏。

【讨论】：

我仍然可以看到潜在的担忧。即使 CosmosDBTrigger 要将消息发布到队列，如果发布到队列时出错会发生什么情况。触发器如何处理异常和失败？是否有任何方法可以保证文档（消息）只传递一次到队列？
此时没有基于事件的触发器具有重试机制。这是设计使然，以避免由于非瞬态异常而导致的无限账单。 Azure Functions 将重试策略添加到触发器后，就可以选择加入重试。

【解决方案2】：

考虑让您的 Azure 函数使用相关负载将消息写入服务总线。然后有第二个函数来读取服务总线并处理有效负载，并为您提供所有熟悉的排队结构，如消息完成/放弃和处理信队列。

【讨论】：