📚 课程目录第3章指数退避策略

3、指数退避策略：让重试学会“等待的艺术”

大家好，我是老张。今天我们来聊聊指数退避——说白了，就是让任务在失败后，别像个愣头青一样马上又冲上去，而是学会“等一等，再等一等”。

你想想看，如果服务已经挂了，你每秒重试一次，跟每秒重试十次，结果有啥区别？都是失败。反而可能把服务彻底压垮。我在项目中就见过这种惨案——一个批量任务因为数据库连接池满了，结果重试策略没配好，直接把数据库打到了404。嗯，从那以后，我对指数退避就特别上心。

3.1 什么是指数退避？

指数退避的核心思想很简单：每次重试的等待时间，按指数级增长。

比如第一次等1秒，第二次等2秒，第三次等4秒，第四次等8秒……这样既给了系统恢复的时间，又不会在初期浪费太多时间。

Prefect 里怎么配？看代码：

from prefect import task, Flow
from prefect.engine.retry import exponential_backoff_retry_handler

@task(
    retry_handler=exponential_backoff_retry_handler(
        retries=5,
        delay=1,           # 初始延迟（秒）
        backoff_factor=2   # 退避因子
    )
)
def my_flaky_task():
    # 你的业务逻辑
    pass

这里 delay=1 是初始等待时间，backoff_factor=2 就是每次翻倍。实际等待时间 = delay × (backoff_factor ^ 重试次数)。

核心公式：

第 n 次重试的等待时间 = initial_delay × (backoff_factor ^ (n-1))

3.2 退避因子详解：不是越大越好

退避因子 backoff_factor 是个关键参数。我见过有人直接设成 10，结果第三次重试就要等 100 秒——任务早超时了。

常见的退避因子取值：

退避因子	特点	适用场景
1.5	温和增长，适合短时抖动	网络超时、连接池短暂耗尽
2.0	标准指数退避，最常用	服务暂时不可用、限流
3.0	激进增长，适合长时间故障	数据库宕机、外部API完全挂掉
1.0	退化为固定间隔（不推荐）	几乎不用，除非你确定故障是瞬时的

我个人习惯：默认用 2.0。如果服务是内部调用、网络延迟稳定，可以降到 1.5。如果是调用第三方 API 且对方经常限流，我会用 2.5 甚至 3.0。

小技巧：退避因子不要设成整数 2 以外的值？其实不是。1.8、2.2 都行。关键是你要理解：因子越大，等待时间增长越快，总重试时间越短（因为重试次数可能用不完就超时了）。

3.3 最大延迟限制：别让等待变成“永恒”

指数退避有个问题：如果不加限制，等待时间会无限增长。比如初始延迟 1 秒，退避因子 2，重试 10 次后，第 10 次要等 512 秒——将近 9 分钟！

所以 Prefect 提供了 max_delay 参数：

@task(
    retry_handler=exponential_backoff_retry_handler(
        retries=10,
        delay=1,
        backoff_factor=2,
        max_delay=60  # 最多等 60 秒
    )
)
def my_task():
    pass

加了 max_delay=60 后，等待时间到了 60 秒就不再增长了。实际等待时间变成：

第 1 次：1 秒
第 2 次：2 秒
第 3 次：4 秒
第 4 次：8 秒
第 5 次：16 秒
第 6 次：32 秒
第 7 次：60 秒（封顶）
第 8 次：60 秒
……

这样既保留了指数退避的初期优势，又避免了无限等待。

注意：max_delay 设得太小会失去指数退避的意义。比如设成 5 秒，那退避因子再大也没用，因为很快就封顶了。我建议 max_delay 至少是 initial_delay 的 10 倍以上。

3.4 实际应用场景：什么时候用指数退避？

指数退避不是万能的。我总结了几种典型场景：

场景一：外部 API 调用

调用第三方服务（支付、短信、地图等），对方可能因为限流或临时故障返回 429/503。这时候指数退避最合适——既尊重对方的限流策略，又不会放弃重试。

@task(
    retry_handler=exponential_backoff_retry_handler(
        retries=5,
        delay=2,
        backoff_factor=2,
        max_delay=30
    )
)
def call_payment_api(order_id):
    # 调用支付接口
    pass

场景二：数据库连接失败

数据库重启或连接池耗尽时，马上重试大概率还是失败。指数退避给了数据库恢复的时间。

我曾经踩过的坑：有一次数据库主从切换，我配了固定间隔 3 秒重试 10 次。结果 30 秒内打了 10 次数据库，每次都是连接失败，还把从库也拖垮了。换成指数退避后，前几次快速失败，后面慢慢等，反而在 20 秒内恢复了。

场景三：分布式锁竞争

多个任务争抢同一个资源时，指数退避可以减少冲突概率。第一次抢不到，等 1 秒再试；还抢不到，等 2 秒……这样大家错开时间，成功率更高。

场景四：文件上传/下载

网络不稳定时，大文件传输容易中断。指数退避配合断点续传，效果很好。

3.5 指数退避的完整流程图

下面这张图展示了指数退避的完整决策流程：

3.6 指数退避 vs 固定间隔：怎么选？

很多新手会问：为什么不直接用固定间隔？简单啊。

我做个对比你就明白了：

维度	固定间隔	指数退避
对系统压力	持续恒定，可能压垮服务	前期密集，后期稀疏，更友好
恢复速度	如果间隔太小，恢复慢	前期快速重试，后期耐心等待
适用场景	瞬时故障（毫秒级抖动）	持续性故障（秒级到分钟级）
配置复杂度	低，一个参数搞定	中等，需要调三个参数
资源浪费	可能浪费大量重试	重试次数少，浪费少

我个人建议：除非你确定故障是毫秒级的，否则优先用指数退避。固定间隔适合的场景太少了——你想想看，如果服务真的挂了，固定间隔重试 10 次跟指数退避重试 5 次，哪个更可能成功？

实战建议：如果你刚开始用 Prefect，先配一个保守的指数退避：retries=5, delay=1, backoff_factor=2, max_delay=30。跑一段时间后，根据日志里的重试次数和等待时间，再微调参数。别一上来就搞激进策略，容易出事。

3.7 小结

指数退避不是银弹，但它确实是生产环境中最常用的重试策略。记住三个关键点：

退避因子控制增长速度，2.0 是黄金起点
最大延迟防止无限等待，建议设成 initial_delay 的 10-30 倍
实际场景中，外部 API、数据库、分布式锁都是指数退避的主战场