Uber Cadence 工作流 Worker 持续轮询导致的扩展限制相关问题

1. 轮询机制是否会引发扩展问题、资源耗尽导致任务丢失 #

• Cadence Worker 的轮询请求不会直接访问底层数据库，所有请求统一提交到 Cadence 服务集群的前端节点，数据库交互、任务队列维护逻辑全部由服务端内部处理，Worker 侧的轮询开销极低，不会因为轮询动作占用过多业务执行资源。
• Worker 支持配置最大并发任务数、轮询请求速率上限，会自动做流控，不会无限制拉取任务。只要根据 Worker 所在节点的 CPU、内存容量合理配置并发阈值，就不会出现资源耗尽崩溃的情况。
• 任务不存在丢失风险：Cadence 服务端派发任务时会绑定执行超时时间，若 Worker 超时未返回执行结果（含崩溃、无响应等场景），任务会自动重新进入任务列表派发给其他健康 Worker 执行。

2. 百万级工作流/任务场景下的扩展能力与延迟表现 #

• Cadence 的任务列表（Task List）采用分片架构实现，单个任务列表的任务会分散存储、调度在多个服务节点上，不存在单点瓶颈，可支撑百万级任务的存储与调度。
• 工作流实例之间完全隔离，状态数据在底层数据库中做分片存储，百万级工作流并行运行时，可通过水平扩展 Cadence 服务集群节点承载增长的负载，不会出现互相干扰的情况。
• 正常负载下任务调度延迟维持在几十毫秒级别。如果出现任务堆积，只要同步扩容匹配任务产生速率的 Worker 数量，即可快速消费堆积任务，不会出现持续的执行延迟；未扩容前也会按照任务生成顺序公平派发，不会出现任务饿死的情况。

内容的提问来源于stack exchange，提问作者Ezio