并行耐久天青函数
我有一个新的持久功能，以取代一个长期运行的网络作业，它工作良好，并比以前的网络作业更快，但我有一个问题的并行性。
我知道所有的活动都放在一个中央工作项目Q上，这意味着按顺序处理项目，我的问题是如果用户A中有10个项目，用户B提交一些东西，那么用户B必须等待用户A的所有数据完成处理。
在现有的网络作业中，我们可以自动升级，一个新的网络作业将为用户B获取数据，并与现有的处理并行处理。
我是否正确地认为，唯一的方法是发布我的函数的两个副本，每个用户/客户端一个副本，以确保一个用户不受另一个用户积压的数据的影响？
我尝试将东西分块到工作项Q上，所以没有单个任务在Q上放置超过X项的内容，这样理论上就会有一些资源共享，但这只是减慢了工作项Q上的资源，因为工作项Q上的资源越少，消耗计划自动缩放的速度就越慢，因为工作项Q上的体积较小。
更新
我应该更清楚为什么我看到这个问题，大概。持久的功能流程如下：
- 将文件拆分为页
- 扇出每一页在q上放一个活动
- 扇入
- 扇出每一页在q上放另一个活动(需要前一个扇出的数据才能运行)
- 扇入
- 在单个事务中将页面信息插入DB中
- 将文件标记为在DB中处理。
因此，用户A加载有1000页的文件1，然后用户B加载100页的文件。
虽然我欣赏它并行地处理活动q，但它仍然按照顺序(我假设)从q中提取东西(我假设)，所以如果在用户B的文件开始时，Q上有1000项，那么最初的100页活动就会在1000之后被放在活动Q上，因此会被它们“阻塞”。然后，当100个初始页面活动完成时，很有可能下一个扇子为1000页文档添加了更多的项目到活动q，进一步阻塞了100页文档的进度。
我的问题是，用户A和B可能是两个不同的客户端，它们的工作不会被另一个客户端的处理所阻止，因此我对具有重复的持久函数实例和在多个实例之间代理消息的评论
这样更有意义吗？
回答 1
Stack Overflow用户
发布于 2019-03-01 01:07:43
的确，活动进入中央工作项队列，但它们做的是，而不是按顺序处理。它们实际上将被并行处理。按照顺序处理事物的唯一方法是，如果只有一个orchestrator函数，并且它有意地对它们进行排序(请参阅功能链)。
如果用户A和用户B的工作是使用不同的业务流程实例完成的，或者使用扇形，扇形的是单个实例，那么您将得到并行化，而不必担心一个用户阻塞另一个用户。
另外，只要FYI，就可以使用host.json来调整并发度。更多细节可以在这里找到：https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#concurrency-throttles
更新
确实，队列是共享的，来自一个业务流程的大量积压可能会导致其他流程中的延迟。在这种情况下，有两种可能的解决办法：
- 添加更多的函数应用实例以更快地处理待办事项。这是在Azure函数消费计划中为您自动完成的，并且一直这样做，直到这个共享队列的延迟变得足够低。
- 为不同的优先级任务创建一个具有第二个任务中心的独立函数应用程序。即使您使用相同的存储帐户，每个任务集线器也会有自己的队列集，因此一个应用程序上的重载不会影响另一个应用程序。
我意识到这些并不是完美的解决方案，因为它们不一定能确保公平。如果公平是一个严格的要求，那么可能需要添加新的功能来支持它(BTW，功能请求可以在持久功能GitHub回购中提出)。
https://stackoverflow.com/questions/50876419
复制相似问题
腾讯云开发者
