Uber Cadence Worker配置及内存/连接异常问题咨询

你的团队遇到的Error 1135（无法创建新线程）和Error 1040（连接数过多）错误，根源就是为每个工作流创建独立Worker的做法——Worker是长驻的资源消耗单元，每个Worker会占用线程、内存，并与Cadence集群及后端数据库保持连接，大量Worker会快速耗尽Pod的系统资源和数据库连接配额。

针对你提出的问题，逐一解答如下：

1. 工作流结束后Worker会自动销毁吗？ #

不会。Worker是独立的任务处理进程/线程，启动后会持续监听指定任务队列，只有显式调用停止API（比如Go SDK的worker.Stop()、Java SDK的worker.shutdown()）才会终止，和单个工作流的生命周期完全无关。

2. 如何合理确定Worker数量？ #

核心原则：Worker是共享的任务处理池，不需要按工作流数量创建。合理数量的评估方式：

• 按服务器资源配置：单台机器的Worker实例数建议和CPU核心数匹配（比如4核机器运行4个Worker实例），避免CPU过载。
• 按任务吞吐量调整：每个Worker内部通过配置并发参数控制任务处理能力，比如MaxConcurrentActivityExecutionSize（最大并发活动数）、MaxConcurrentWorkflowTaskExecutionSize（最大并发工作流任务数），根据业务的任务量调整这些参数，而不是增加Worker实例数。
• 参考最佳实践：Cadence官方推荐复用Worker实例，一个Worker可以处理成百上千个工作流的任务，不需要为每个工作流单独分配Worker。

3. 如何查看连接到Cadence集群的Worker数量？ #

有几种方式：

• 使用Cadence CLI：
  • 查看集群整体Worker统计：cadence cluster describe
  • 查看指定任务队列的Worker：cadence task-queue describe --task-queue <你的任务队列名称>
• 监控工具：如果集群配置了Prometheus，可以通过cadence_workers指标获取各任务队列的活跃Worker数量。
• Web UI：在Cadence Web控制台的任务队列详情页，能直接看到当前绑定的活跃Worker数。

4. Worker会被长时间等待的工作流阻塞吗？ #

不会。Worker采用任务拉取模式：只在有可执行任务（工作流任务、活动任务）时才会占用资源处理，当工作流进入等待状态（比如等待审批），Worker会完成当前工作流任务的处理并释放资源，继续拉取队列中的其他任务。哪怕只有一个Worker，也能同时处理多个工作流的任务，不会被长时间等待的工作流阻塞。

验证建议 #

修改为单Worker是完全符合Cadence设计理念的，也是标准用法。测试时重点关注：

• Pod的内存、线程数、数据库连接数是否回归正常水平
• 工作流的全流程执行（包括等待审批后的唤醒）是否正常

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