我正在评估实施业务编排的节奏。我了解工作人员不断轮询任务列表以执行要执行的任务。我在这里担心的是它会导致任何规模问题吗？ Worker 总是很忙，不断地轮询一些数据库，同时它还需要执行业务逻辑，所以它是否有可能耗尽资源然后崩溃或放弃要执行的任务？
当我们拥有数百万个工作流时，这种轮询机制如何扩展？当我们在任务列表中有数百万个任务时，它会导致执行工作流代码的延迟吗？
【问题讨论】：
标签： cadence-workflow temporal-workflow uber-cadence
除了Maxim的答案之外的一些指示- 只要您正确设置，Cadence/Temporal 就不存在缩放问题。
当您在 tasklist(taskqueue) 中有数百万个任务，并且需要运行数千个工作人员来处理这些任务时，请确保您配置具有更多分区的可扩展任务列表。
基本上，默认情况下，任务列表仅使用一个分区，该分区映射到一个 db 分区（如果使用 Cassandra 或多个 SQL 或其他 NoSQL），并由一个匹配的主机拥有。因此它的可扩展性不足以为数千个工作主机和数百万个任务提供服务。因此，您需要通过添加更多分区来扩展任务列表。否则匹配的主机会运行得太热，DB 分区会是热分区（并且具有高延迟）。
请参阅有关如何启用可扩展任务列表功能的文档：https://cadenceworkflow.io/docs/operation-guide/maintain/#scale-up-a-tasklist-using-scalable-tasklist-feature
【讨论】：
Cadence 和 Temporal 通过 gRPC 使用 long polling 来监听任务队列。因此，如果队列中没有消息，则轮询请求每分钟返回一次。这样工人就不会因为轮询而消耗过多的资源。此外，由于匹配服务实施的各种优化，大多数轮询调用不会导致对数据库的调用。
打开的工作流的数量根本不会影响轮询性能，因为其中许多工作流可以被动地等待外部事件的计时器。工作流每秒执行的操作数定义了必须将多少任务交付给工作人员。如果集群和工作人员配置正确，那么即使是高频率的任务也不应该导致任何问题。
【讨论】：