我们有以下设置：
Event Hub —-> Azure Function —> API.
我们正在尝试使用 Event Hub 提出死字解决方案。事件中心不附带 Dead Lettering，因此我们需要构建自己的解决方案。
我们想出了两个选项：
带有事件中心触发器的 Azure 函数，将有 try catch 块，它确实有一个重试策略来调用 Api，如果在所有尝试后调用失败，我们将存储事件，元数据（事件的偏移量）在天蓝色表存储，以便我们可以使用 DLQ 重新处理器从表存储中重新处理此事件。
带有事件中心触发器的持久功能。将具有编排器和活动功能。如果处理事件因错误而失败，我们可以重试活动函数，因为它已经持久化了。
我想知道这里哪个选项更好。我无法理解持久函数的确定性政策是如何在这里发挥作用的。
我们尝试了选项 1，感觉我们正在 Azure 存储中构建状态机。我们期待内置的 azure 持久函数是否能帮助我们处理死字和弹性。
您的两个选项在核心上都是相同的实现，除了 Durable Functions 具有您已经需要的一切这一事实。
这里有一些可以帮助您使用持久功能设置一切的东西
1。利用具有活动功能的自动重试
这将确保即使出现间歇性问题，每个编排的第一次运行也能完成。
2。在 Instance Management APIs
之上构建 Dead Lettering
由于总是有可能出现其他问题并需要修复（这就是您问这个问题 🙂 的原因），Durable Functions 已经附带了 API，允许您查询失败的实例并按需重新运行它们。
根据您的场景，您可以按计划或事件调用这些 API。
3。如果需要，请使用 Netherite 存储提供程序
根据应用程序的规模，您可以考虑使用此存储提供程序而不是默认的 Azure 存储提供程序。
但在采取行动之前，您可能需要评估转换的规模和成本效益。您可以在他们的官方文档中阅读有关该引擎的更多信息。