并行持久Azure功能

Question

我有一个新的持久功能来替换长时间运行的webjob并且它运行良好并且比以前的webjob更快但是我遇到并行问题。

我理解所有活动都进入了一个中心工作项Q，这意味着项目按顺序处理，我遇到的问题是，如果用户A的待办事项中有10个项目，则用户B提交的内容然后是用户B必须等到用户A的所有数据都已完成处理。

使用当前的webjobs，我们可以自动缩放，新的webjob将为用户B提取数据，并将其与现有处理并行处理。

我是否正确地认为，唯一的方法是发布我的功能的两个副本，每个用户/客户一个副本，以确保一个用户不受另一个用户积压数据的影响？

我尝试在工作项Q上进行分块，因此没有任何单个任务在Q上放置超过X个项目，因此理论上会有一些资源共享但这会减慢事情，因为工作项目Q更少因此，由于工作项Q的体积较小，消耗计划自动缩放的速度非常缓慢。

更新

我应该更清楚地知道为什么我会看到这个问题。持久功能过程如下：

• 将文件拆分为页面
• 扇动将活动放在每页的Q上
• Fan In
• 指出每个页面的Q上放置另一个活动（需要 以前扇出的数据运行）
• Fan In
• 在单个交易中将页面信息插入数据库
• 将文件标记为在数据库中处理

因此，用户A加载具有1000页的文件1，然后用户B加载具有100页的文件。

虽然我很欣赏它并行处理活动Q但它仍然按顺序从Q中取出（我假设），所以如果用户B的文件中有1000个项目用户B＆＃39; s文件开始，然后在1000之后将最初的100页活动放到活动Q上，因此被阻止＆＃34;被他们。然后，当100个初始页面活动完成时，1000页文档的下一个扇出很可能会再次向活动Q添加更多项目，从而进一步阻止100页文档的进度。

我的问题是用户A和B可能是2个不同的客户，他们不希望他们的工作被另一个客户端的处理阻止，因此我评论有关Durable函数的重复实例和多个代理之间的消息实例

这是否更有意义？

Answer 1

的确，活动进入中央工作项目队列，但不不会按顺序进行处理。它们实际上将并行处理。只能按顺序处理事物的唯一方法是，只有一个协调器功能并且有意对它们进行排序（请参见function chaining）。

如果用户A和用户B的工作是使用不同的编排实例完成的，或者如果它的单个实例使用fan-out, fan-in pattern，那么您将获得并行化，而不必担心一个用户被阻塞另一个。

此外，仅供参考，您可以使用host.json调整并发度。可在此处找到更多详细信息：https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#concurrency-throttles

更新

的确，队列是共享的，一个业务流程的大量积压可能会导致其他业务流程的延迟。在这种情况下，有两种可能的解决方案：

1. 添加更多功能应用实例以更快地处理积压。这将在Azure Functions消耗计划中自动为您完成，并持续进行直到此共享队列的等待时间足够短为止。
2. 使用另一个任务中心创建一个单独的功能应用程序，以处理不同优先级的作业。即使您使用相同的存储帐户，每个任务中心也会有自己的队列集，因此一个应用程序的繁重负载不会影响其他应用程序。

我意识到这些并不是完美的解决方案，因为它们不一定能确保公平。如果对公平性有严格的要求，则可能需要添加新功能来支持它（顺便说一句，可以在Durable Functions GitHub repo中提出功能请求。