Cadence/Temporal工作流中信号处理的最佳方法与实现模式

直接在Signal方法内编写业务处理逻辑是官方文档入门示例的简化写法，生产环境使用会遇到顺序错乱、竞态、重置异常、提前终止四类问题，行业内通用的落地方案是信号接收与处理完全解耦的队列消费模式，具体实现和适配逻辑如下：

标准实现代码 #

public class MyWorkflow {
    // 初始化SDK自带的工作流安全队列，设置合理的队列长度上限
    private final WorkflowQueue<SignalRequest> signalQueue = Workflow.newWorkflowQueue(100);
    private boolean workflowFinishFlag = false;

    public Output myWorkflowMethod(Input input) {
        // 工作流初始化逻辑
        Output result = initWorkflowState(input);

        // 主消费循环
        while (!workflowFinishFlag || !signalQueue.isEmpty()) {
            // 阻塞等待下一个信号，设置短超时避免工作流长时间空轮转
            SignalRequest request = signalQueue.poll(Duration.ofSeconds(30), WorkflowQueue.DrainMode.POLL_UNTIL_STOPPED);
            if (request == null) {
                continue;
            }
            // 单线程串行处理信号
            processSignalRequest(request);
            // 校验是否满足业务结束条件
            if (matchFinishCondition(result)) {
                workflowFinishFlag = true;
            }
        }
        return result;
    }

    // Signal方法仅做入队操作，不包含任何业务逻辑
    public void mySignalMethod(SignalRequest request) {
        signalQueue.offer(request);
    }
}

对四类问题的适配说明 #

• FIFO串行处理保障：所有信号不管信号名是否一致，统一进入工作流安全队列，主工作流线程单线程逐个拉取队列元素处理，天然保证全局FIFO顺序。如果需要给不同信号名设置处理优先级，也可以拆分多个独立队列，主循环按优先级轮询消费即可，同信号名的先后顺序不会被打乱。
• signalWithStart竞态修复：Signal方法本身不做任何业务逻辑，只执行最简单的入队操作，完全不依赖工作流初始化状态。不管信号是在工作流启动前随start请求送达，还是工作流运行中送达，只会被暂存到队列里，等工作流主逻辑完成初始化后才开始消费处理，从根源上避免信号触发时工作流状态未就绪导致的空指针、状态错乱问题。
• 工作流重置兼容：重置操作触发历史重放时，所有需要重放的信号会按照原有历史顺序重新执行入队操作，主循环会严格按照重置点后的事件顺序重新处理信号，不会出现重复处理、漏处理、顺序错乱问题。队列的入队、消费操作完全由工作流历史事件驱动，重放时会1:1复刻执行路径，只需要业务处理逻辑本身做好幂等即可，不需要额外写兼容逻辑。
• 提前终止防护：主循环的退出条件做了双重校验：只有标记了工作流结束且待处理信号队列为空时，才会退出循环返回结果。哪怕已经满足业务上的结束条件，只要还有未消费的信号，工作流就会持续运行直到所有信号处理完成，彻底避免信号丢数、未处理完就终止的问题。

核心原则：Signal方法里绝对不要写任何业务判断、状态修改、处理逻辑，它的唯一作用就是把收到的信号请求存入队列。所有业务处理逻辑全部放在主工作流线程的消费环节执行，这是规避所有Signal相关异常的核心。

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