Azure持久功能-扇出扇入可扩展性

我们是一家以技能为基础的开发公司，创造竞争。本次比赛的玩家可以上传照片，并对彼此的照片进行排名以获得积分。其中一个关键要求是定期更新竞赛领导委员会，以保持运动员的兴趣。我们正在寻找一个扇出和扇入的架构来实现leader board。附上典型的工作流程

从我们的分析来看，耐用功能似乎是最佳选择

然而，我们有以下限制

每场比赛约有500名选手

一名玩家最多可对500张照片进行排名

---

我一直在努力阅读文档。但是，我们找不到关于使用持久功能的这种方法的可伸缩性的文档。非常感谢您的评论或见解

您可以在此处找到耐用功能的性能目标：

并行活动执行（扇出）每秒100个活动，每个实例

并行响应处理（扇入）每秒150个响应，每个实例

如果您在Azure功能使用计划上运行，则随着更多消息出现在工作项队列中，那里的缩放控制器将缩放到更多实例。 这是用于启动活动的队列（用于计算单个玩家的分数）

您还可以按照文档中的说明来提高扇入性能：

与扇出不同，扇入操作仅限于单个VM。如果应用程序使用扇出、扇入模式，并且您担心扇入性能，请考虑将活动功能扇出细分为多个子业务流程。

所以你会：

• 主配器
  • 批处理0子编排器
    • 批处理0中用户0的活动
    • 批处理0中用户1的活动
  • 第1批子编排器
    • 批处理1中用户0的活动
    • 批处理1中用户1的活动

这种子orchestrator批处理之所以更快，是因为随着活动的完成，orchestrator历史记录表中的行越来越多。 每次有结果时，它都必须加载这些。 因此，通过限制这些行的上限，可以获得最大的性能

TL；DR：我认为扇出可以很好地扩展，但是您可能希望执行子编排器批处理来提高扇出性能