为何Cadence中旧决策任务阻塞，新任务却能被快速调度？

核心原因分析 #

• 粘性任务列表的绑定限制：旧工作流的决策任务通过粘性列表绑定到了特定worker进程/节点，如果该worker因负载过高、资源耗尽或进程异常无法处理任务，任务会一直卡在绑定队列中。只有当StickyScheduleToStartTimeout超时后，任务才会被移到全局任务列表重新分配。若该超时设置过长（比如接近24小时），就会出现长时间阻塞。而新工作流的任务未绑定到特定worker，会被调度到可用的空闲worker，因此能快速处理。
• 工作流历史长度差异：旧工作流积累了大量历史事件，决策任务需要加载、解析和处理这些历史数据，CPU/IO开销远高于新工作流。在服务器负载高时，这类高开销任务更容易因资源争抢出现超时或阻塞，而新工作流历史短，处理成本低，能快速完成。
• 分区负载不均衡：尽管配置了50个分区，但旧工作流可能因哈希策略集中在少数几个分区，这些分区的poller（125个总量）分配不足，或者对应worker节点负载饱和。新任务则可能被分配到负载较低的空闲分区，得到及时处理。
• 任务超时配置不合理：旧决策任务的ScheduleToStartTimeout或StartToCloseTimeout设置过长，导致任务在队列中持续等待而未触发重试或重新分配逻辑。新任务的超时配置更合理，能快速流转。

排查与解决建议 #

• 调整粘性任务超时：缩短StickyScheduleToStartTimeout（比如设置为5-10分钟），让绑定worker不可用时，任务能更快切换到全局列表被其他poller处理。
• 优化工作流历史：对运行时间长的旧工作流使用ContinueAsNew操作截断历史，减少决策任务的处理开销。
• 平衡分区负载：监控各分区的任务堆积情况，调整poller的分布策略，确保每个分区都有足够的poller资源；必要时调整工作流到任务列表的哈希规则，避免任务集中在少数分区。
• 检查worker状态：排查绑定旧任务的worker节点是否存在CPU、内存、网络瓶颈，及时扩容或重启异常worker，恢复任务处理能力。
• 调整任务超时配置：合理设置ScheduleToStartTimeout和StartToCloseTimeout，确保任务在超时后能被重新调度，避免无限期阻塞。

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