代码之家 › 专栏 › 技术社区 › Anonymous1

Azure函数扇出/扇入,没有持久函数

azure-queues azure-functions azure

0

Anonymous1 · 技术社区 · 7 年前

我有两个按顺序运行的Azure队列触发器,一个是WebJob,另一个是Azure函数。第一个队列触发器生成第二个队列触发器接收的许多消息。问题是,第一个队列触发器生成第二个队列触发器都使用的blob,我希望在第二个队列触发器全部完成后删除该blob。

最明显的解决方案是将队列转换为具有扇出/扇入设计模式的持久函数,但我希望避免这种情况,因为队列会给我自动重试/中毒队列,并且已经设置并与其他现有代码一起工作,这些代码在第二个队列全部完成后不需要删除blob。

我已经提出了一些潜在的解决方案,但我仍然对Azure函数和WebJobs比较陌生,所以我希望得到反馈。它们都使用解决方法异步计算第二个队列触发器的完成情况,并在最后一个队列触发器完成时从第二个队列触发器中删除blob。

解决方案1:

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

解决方案2:

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

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

有更多使用Azure函数和WebJobs经验的人有什么建议吗?

1 回复 | 直到 7 年前

1

0

Mikhail Shilkov 7 年前

解决方案2与持久性函数在后台所做的非常类似,因此它可以工作,但是实现和调试的负担就在您身上。在处理重试时,您可能会遇到一些并发性问题、不确定因素等。如果您的解决方案不需要非常健壮,那么就开始吧。

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

我怀疑扇入存在一个替代的、琐碎的和正确的解决方案。