基础重试机制：retry指令的引入、基本用法、重试次数和间隔设置

聊到失败重试，很多人第一反应就是“失败了再跑一次”。但在生产环境里，简单的暴力重试往往会浪费大量资源——有些错误是瞬时的，重试有用；有些错误是系统性的，重试只会让情况更糟。那Nextflow怎么解决这个问题的？它提供了一个非常自然的retry指令，让你用声明式的方式控制重试行为，而不需要手写脚本循环。

从errorStrategy到retry指令

早期的Nextflow流程里，重试大多靠errorStrategy 'retry'配合maxRetries来实现。比如这样：

process myProcess {
    errorStrategy 'retry'
    maxRetries 3
    maxErrors 5

    script:
    """
    your_command_here
    """
}

这个写法其实也能工作，但它有个缺点——重试间隔是固定的，默认就是立即重试，没有任何等待。你想想看，如果故障是因为网络抖动或者资源暂时耗尽，立刻重试大概率还是失败。我在项目里就踩过这个坑：一个SRA下载流程，文件服务器偶尔503，我设了maxRetries 5，结果5次都在同一秒内触发，全挂了。

后来Nextflow社区引入了更灵活的retry指令，它把重试次数、间隔策略、退避因子这些东西统一放在一个声明里。我个人习惯是，新写的流程统一用retry，不再用老的办法。

retry指令的基本用法

最简单的用法就是指定重试次数和等待时间。举个例子：

process downloadData {
    retry with: 3 times, 5.minutes

    script:
    """
    wget http://example.bio/data.bam
    """
}

这段代码的意思是：如果进程退出码非零（或者捕获到异常），最多重试3次。每次重试之间固定等待5分钟。注意，这个“5分钟”是从上一次启动开始算，不是从上一次失败开始算。嗯，这里要留意一下，Nextflow的等待时间是相对于进程启动时刻的，类似于cron的精度。

当然你也可以不写时间单位，直接用数字和默认单位：

process align {
    retry with: 5 times, 10

    script:
    """
    bwa mem ref.fa sample.fq > aligned.sam
    """
}

这里的10表示10秒。Nextflow支持seconds、minutes、hours这些单位，也支持不带单位的数字自动识别为秒（我印象里是秒，但保险起见还是显式写单位比较好）。

重试间隔策略：从固定到指数退避

固定间隔虽然简单，但在某些场景下不够智能。比如一个高并发作业调度系统，如果大家都在等5秒后重试，那5秒后又会形成一波新的冲击。更好的做法是指数退避（exponential backoff）。

Nextflow的retry指令支持设置一个乘法因子（multiplier），让等待时间逐次增长：

process heavyJob {
    retry with: 4 times, 1.minute, 2.0

    script:
    """
    gpu_training_script.sh
    """
}

这里每次等待时间是前一次的2倍：第1次等待1分钟，第2次2分钟，第3次4分钟，第4次8分钟。注意，这个乘法是从第2次重试开始生效的，第一次等待时间是初始值。

为什么是指数退避？我记得有一次做基因组组装，集群的临时存储满了，我们设了固定3分钟重试。结果每次重试都还是满的，因为其他作业也在同时写文件。换成指数退避后，第三次重试时存储已经释放了，流程就跑过去了。说白了，指数退避给了系统一个“喘口气”的时间。

增加随机抖动，避免雷暴

即使用了指数退避，如果多个进程都在同一时刻触发重试，依然可能造成周期性压力。这时候可以加上随机抖动（jitter）。Nextflow没有直接的jitter参数，但你可以通过maxDelay来控制上限，再加上randomized选项：

process elasticJob {
    retry with: 3 times, 30.seconds, 1.5, maxDelay: 10.minutes, randomized: true

    script:
    """
    some_remote_api_call.sh
    """
}

这里的randomized: true会在每次计算出的延迟值上加上一个随机因子（通常是±50%），让重试时间散开。实际等待时间 = 计算值 × (1 + 随机偏移)。这个功能在调用外部API时特别有用——我曾经见过一个同事的流程，因为没有加抖动，重试时把所有请求打到了同一秒，直接把API限流给触发了。

参数速查表

下面这个表格总结了retry with:的主要参数，方便你快速参考：

retry指令的完整示例

让我们看一个更实际的场景：一个RNA-seq定量流程，需要从远程FTP下载参考文件，偶尔会连接超时。我一般会这样写：

process downloadReference {
    retry with: 5 times, 10.seconds, 2.0, maxDelay: 2.minutes, randomized: true

    script:
    """
    wget -O ref.fa ftp://example.com/genomes/hg38.fa.gz
    """
}

这段配置的意思是：最多重试5次，第一次等10秒，之后每次乘2（20秒、40秒、80秒、160秒），但最长不超过2分钟。再加上随机抖动避免同时重试。我实际用过类似的配置跑过1万多次下载，成功率达到99.9%以上，剩下的0.1%是服务器彻底挂了，重试也没用。

重试与资源消耗的平衡

重试次数不是越多越好。我见过有人设20次重试，结果一个流程跑了快两天，全在重试里浪费了。标准做法是：

• 瞬时故障（网络超时、资源排队）：3~5次，指数退避 + 抖动
• 半持久故障（磁盘满、认证过期）：1~2次，快速检查后放弃
• 持久故障（代码bug、数据损坏）：不重试，直接失败并告警

另外，如果工作流里多个进程有依赖关系，重试时要注意下游会不会被阻塞。Nextflow的DAG调度会等上游完成才启动下游，所以重试期间下游任务会自动等待，不会浪费计算资源。但如果你的集群按核时计费，长时间等待重试也算墙钟时间，小心账单。

params.retry_times = 3
params.retry_delay = 30.seconds

process myProcess {
    retry with: params.retry_times, params.retry_delay
}

不支持retry指令的场景

虽然retry指令非常方便，但有些情况它帮不上忙：

• 输入文件不存在：如果输入文件丢失，重试没有意义。
• 内存溢出（OOM）：需要调整资源分配，重试只会继续OOM。
• 工作目录冲突：多个进程写同一个临时文件导致锁冲突，重试可能还是撞上。

在这些情况下，你应该使用errorStrategy 'ignore'配合自定义检查，或者干脆让流程失败后手动处理。

retry背后的执行逻辑

下面这张流程图概括了retry指令在运行时的工作流程：

这张图把retry的决策路径画得很清楚。每次失败后先看次数是否用完，没用完就根据策略计算延迟再重试。整个过程中，进程的工作目录和输入文件都是不变的——所以如果你的脚本有副作用（比如生成临时文件），要小心清理。

什么时候该用retry指令？

我个人的经验法则很简单：只要错误是可恢复的、偶发的，就用retry。比如网络请求、远程文件读写、资源排队、短暂的高负载。如果是代码逻辑错误、数据格式问题、或者资源配额已经用完（比如硬盘100%满了），重试只会浪费时间和计算资源。这时候应该让流程停止，人工介入。

另外，别忘了retry和errorStrategy可以一起用。比如你想对某些错误忽略、某些错误重试：

process mixed {
    errorStrategy 'retry'
    maxRetries 2
    retry with: 3 times, 1.minute, 2.0

    script:
    """
    risky_command
    """
}

这种情况下，errorStrategy 'retry'控制的是错误处理模式（自动重试），而retry with控制的是重试的具体参数。两者配合使用时要小心——maxRetries可能会覆盖retry with里的次数设定。我建议只选一种方式，混用容易混乱。