0

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

我知道所有活动都进入一个中心工作项 Q，这意味着项目按顺序处理，我遇到的问题是，如果用户 A 的积压工作中有 10 个项目并且用户 B 提交了一些东西，那么用户 B 必须等待直到用户 A 的所有数据处理完毕。

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

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

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

更新

我应该更清楚为什么我会看到这个问题，大约。Durable Function 流程如下：

  • 将文件拆分为页面
  • 扇出在每个页面的 Q 上放置一个活动
  • 扇入
  • 扇出为每个页面在 Q 上放置另一个活动（需要先前扇出的数据才能运行）
  • 扇入
  • 在单个事务中将页面信息插入数据库
  • 将文件标记为在数据库中处理

所以用户 A 加载文件 1 有 1000 页，然后用户 B 加载文件有 100 页。

虽然我很欣赏它并行处理活动 Q，但它仍然按顺序从 Q 中拉出东西（我假设）所以如果用户 B 的文件启动时用户 A 的文件 Q 上有 1000 个项目，那么最初的 100 个页面活动就会得到在 1000 之后执行活动 Q，因此被他们“阻止”。然后，当 100 页初始活动完成时，很有可能下一次对 1000 页文档的扇出将再次向活动 Q 添加更多项目，从而进一步阻止 100 页文档的进度。

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

这是否更有意义？

4

1 回答 1

0

确实，活动进入中央工作项队列，但它们没有按顺序处理。它们实际上将被并行处理。按顺序处理事情的唯一方法是，如果只有一个协调器函数并且它有意对它们进行排序（请参阅函数链接）。

如果用户 A 和用户 B 的工作是使用不同的编排实例完成的，或者如果它是使用扇出、扇入模式的单实例，那么您将获得并行化，而不必担心一个用户阻塞其他。

此外，仅供参考，您可以使用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存储库中提出功能请求。

于 2019-03-01T01:07:43.557 回答