Uber Cadence工作流Worker协程控制与长时运行协程问题咨询

1. Workflow Worker是否具备协程数量管控能力 #

• 具备完整的协程数量管控能力，相关逻辑是Cadence SDK内置实现的，不需要业务代码额外开发管控逻辑
• 核心管控维度有两个：
  • MaxConcurrentWorkflowTaskExecutionSize：Worker同时处理工作流任务的最大并发硬阈值，也就是同时处于运行状态的工作流执行协程的数量上限。超过阈值后Worker会停止从Cadence服务端拉取新的工作流任务，从入口避免无限制创建协程打满CPU、内存资源，官方Go/Java SDK的默认值为100，业务可以根据部署机器的硬件配置自行调整
  • WorkflowCacheSize：控制同时驻留在内存中的工作流执行上下文最大数量，超过阈值的闲置工作流上下文会被序列化后从内存清退，释放占用的协程、内存资源
• 工作流代码中通过SDK提供的workflow.Go方法启动的业务协程，会被SDK内置的调度器统一调度管理，不会直接无限制映射为语言层面的原生协程/系统线程，正常使用不会出现协程泄漏问题。

2. 长时运行工作流（含Sleep场景）是否会生成大量协程 #

• 不会，这是Cadence和传统长驻进程执行模型最核心的设计差异
• Cadence的工作流本质是事件驱动的持久化状态机，不会靠常驻协程阻塞等待长时间操作：
  • 当工作流执行到workflow.Sleep、等待活动任务返回结果、等待外部信号这类需要长时间挂起的逻辑时，SDK不会保留协程阻塞等待，而是会把当前工作流的全量执行状态序列化后持久化到Cadence服务端，直接销毁当前工作流对应的执行协程、释放所有占用的内存资源，同时在服务端注册对应的触发事件（比如Sleep对应的定时唤醒事件）
  • 只有等对应的触发事件到达（比如Sleep计时结束、活动执行完成、收到外部信号），服务端才会把工作流的历史状态推送给可用的Worker，Worker重新拉起协程，从上次暂停的位置继续执行后续逻辑；如果执行完当前批次逻辑后再次进入等待状态，会再次释放协程资源
• 哪怕同时运行数十万、上百万个处于Sleep等待状态的长时工作流，实际占用的协程数量也只会维持在配置的并发处理上限以内，完全不会因为工作流运行时间长、等待步骤多就产生大量常驻协程。
• 注意：如果在工作流代码里误用语言原生的sleep、原生协程启动方法，才会出现协程常驻、资源泄漏的问题，必须使用SDK提供的对应工作流API才能获得上述资源管控能力。

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