Cadence在各类故障场景下的错误处理机制是怎样的？

Cadence的错误处理逻辑和故障场景强绑定，不同层面的故障对应不同的内置处理策略，具体如下：

1. 活动（Activity）执行故障 #

活动是Cadence中执行业务逻辑的核心单元，执行阶段的故障处理逻辑如下：

• 瞬时可重试故障：针对网络抖动、下游服务临时不可用、短时间资源不足这类故障，你可以提前配置活动的重试规则（最大重试次数、重试间隔、退避系数、可重试错误白名单），Cadence会自动按照规则重试，不需要在业务代码中额外实现重试逻辑，重试状态会持久化到集群，不会随Worker故障丢失。
• 明确不可重试故障：如果是参数非法、权限不足、业务校验不通过这类不可能通过重试解决的错误，你可以在活动代码中返回NonRetryableError类型，Cadence收到后会直接终止重试，将错误透传给上层工作流处理。
• 超时故障：如果活动触发了提前配置的ScheduleToStartTimeout（调度到Worker启动的超时，通常由Worker资源不足触发）、StartToCloseTimeout（活动执行总时长超时），Cadence会判定活动执行失败，按配置执行重试或直接返回错误。

2. 业务Worker节点故障 #

即运行Cadence工作流、活动的业务进程/所在机器宕机的场景：

• 正在执行的活动：Cadence不会直接判定活动失败，等对应活动的超时时间到期后，会将该活动任务重新调度给其他正常运行的Worker执行，你只需要保证活动逻辑具备幂等性即可。
• 正在执行的工作流：工作流的所有执行状态、历史记录都持久化存储在Cadence集群中，Worker故障后，Cadence会将该工作流的决策任务重新派发给其他可用Worker，Worker会从最近的决策点开始重放执行历史，自动恢复到故障前的执行状态，整个过程不需要业务侧做额外的状态持久化处理。

3. Cadence集群自身故障 #

即Cadence服务端节点、存储层出现异常的场景：

• Cadence服务端默认多副本部署，核心元数据、工作流执行数据都持久化存储在Cassandra/MySQL中，单节点故障不会造成数据丢失，集群自带的故障转移逻辑会自动将故障节点的流量切到正常节点。
• 集群异常期间提交的工作流请求会返回失败，业务侧做简单的请求重试即可；已经在运行的工作流不会丢失，集群恢复正常后会自动继续执行。

4. 工作流逻辑异常 #

即工作流代码本身的问题导致的故障：

• 非确定性错误：如果工作流代码违反了Cadence的约束（比如直接调用系统随机数、系统时间，没有使用Cadence提供的对应API，导致执行历史重放时路径和原执行路径不一致），Cadence会抛出NonDeterministicError，将工作流转为失败状态，方便快速排查代码问题。
• 业务逻辑错误：工作流执行中抛出的业务异常，可以直接在工作流代码中捕获处理，比如触发已执行活动的补偿逻辑、按分支逻辑继续执行，或是直接终止工作流返回错误。

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