没有持久函数的 Azure 函数 fan-out/fan-in

Question

我有两个按顺序 运行 的 Azure 队列触发器，一个是 WebJob，另一个是 Azure Function。第一个队列触发器生成许多消息，这些消息被第二个队列触发器拾取。问题是第一个队列触发器生成一个 blob，第二个队列触发器全部使用，我想在第二个队列触发器全部完成后删除该 blob。

最明显的解决方案是使用 fan-out/fan-in 设计模式将队列转换为持久函数，但我宁愿避免这种情况，因为队列给我自动 retry/poison 队列并且已经设置好启动并与其他现有代码一起运行，这些代码不需要在第二个队列全部完成后删除 blob。

我提出了几个可能的解决方案，但希望得到反馈，因为我对 Azure Functions 和 WebJobs 还是比较陌生。它们本质上都使用变通方法来异步计算第二个队列触发器的完成情况，并在最后一个队列触发器完成时从第二个队列触发器中删除 blob。

解决方案 1：

让第一个队列触发器创建一个临时队列。在将原始队列消息添加到第二个队列之前，将与原始队列消息相同数量的队列消息添加到临时队列。每次第二个队列触发器完成处理其中一条原始消息后，从临时队列中取出一条消息。在最后一项从临时队列中出队后删除 blob 和临时队列。

解决方案 2：

在存储帐户中创建一个 table。在将队列消息添加到第二个队列之前，将具有 blob 名称和总消息计数的行插入 table。在第二个队列触发器完成对其中一条消息的处理后，插入包含 blob 名称的行。在插入的行数等于计数后，删除 blob 和 table 行。

我还想到了其他可能的解决方案，例如在存储帐户中使用 Redis 缓存而不是 table，或者在一段时间后删除临时文件而不是尝试计算完成次数，但上面的两个解决方案似乎是迄今为止最有希望的。

有没有使用 Azure Functions 和 WebJobs 有更多经验的人有什么建议？

Answer 1

解决方案 2 与 Durable Functions 在幕后所做的非常相似，因此，它会起作用，但实施和调试的负担由您承担。您可能会遇到一些并发问题、处理重试时的不确定性等。如果您的解决方案不需要非常健壮，那就去做吧。

如果问题只是删除 blob 文件，我可以想象一个更简单的解决方案。例如。发送另一条延迟的消息，例如1小时删除它，而你知道你的处理时间总是不到一小时。或者只是定期清理旧文件。

我怀疑扇入是否存在替代的、简单的和正确的解决方案。