📚 课程目录第4章重试策略核心参数配置

重试策略核心参数配置：最大重试次数、间隔策略、超时时间

崩溃上报系统的韧性高度依赖于重试策略的合理配置。参数不当会导致：重试风暴（服务端被打满）、无效重试（每次都立刻超时）、资源泄露（上报队列撑爆内存）。本章将拆解三个核心参数的原理、配置方法及工程权衡。

4.1 参数职责总览

参数	职责	影响范围
max_retries	限制重试总次数，防止无限重试	上报延迟、服务端压力
interval_strategy	控制每次重试前的等待时间	突刺平滑、时效性
timeout	单次上报请求的最大耗时	队列阻塞、线程池饥饿

4.2 最大重试次数（max_retries）

原理：重试次数与可用性成对数关系——第一次重试成功概率 p₁ = p₀，第二次重试成功概率 p₂ = p₀ ⋅ (1 - 失败的独立概率)？实际上每次重试的可能结果相互独立，但服务端瞬时故障通常在 2～3 次后恢复。经验表明：max_retries = 2 可以覆盖 90% 的瞬时故障，max_retries = 3 覆盖 98%。超出后收益递减明显。

典型配置：

# TOML 配置片段
[retry]
max_retries = 3
retry_on = ["network_error", "server_error_5xx"]

4.3 间隔策略：指数退避 vs 固定间隔

策略	公式	适用场景	风险
固定间隔	wait = `base_delay`	后端有独立限流、重试数极少（如 max_retries = 1）	高并发时放大突刺
指数退避	wait = `base_delay * 2^attempt`	服务端瞬时过载、雪崩防护	首次延迟可能过短
带抖动的指数退避	wait = random(0, `base_delay * 2^attempt`)	大规模客户端群同时重试	需额外随机数开销

⚠ 经典陷阱：固定间隔 + 大量客户端同时重试 = 对服务端的“心跳攻击”。必须配合抖动（jitter）或至少使用指数退避。

实现代码（Python 示例）：

def compute_delay(attempt: int, base_ms: int = 200, jitter: bool = True) -> float:
    sleep = base_ms * (2 ** attempt)
    if jitter:
        sleep *= random.uniform(0.5, 1.0)   # 添加 50% 抖动
    return sleep / 1000.0   # 转为秒

4.4 超时时间（timeout）

超时保护是整个重试链路的第一道哨兵。如果单次请求超时特别长（比如 30s），那么 3 次重试会消耗 90s，队列会被阻塞。推荐根据崩溃数据包大小设定：

小型崩溃（< 1 MB）：timeout = 3s
中型崩溃（1～10 MB）：timeout = 10s
大型崩溃（> 10 MB）：timeout = 30s 或分片上传

配置示例（JSON 风格的 API 初始化）：

{
  "retry": {
    "max_retries": 3,
    "strategy": "exponential_backoff",
    "base_delay_ms": 200,
    "timeout_ms": 5000
  }
}

4.5 组合参数决策流程

下面的 SVG 图展示了一个上报模块初始化时，如何根据崩溃大小与环境负载决定重试参数。

4.6 常见配置错误与性能优化

✅ 最佳实践

始终为指数退避添加随机抖动，避免惊群效应。
超时时间应小于队列轮询间隔（如 app_sleep_ms 的 1/3）。
记录每次重试的 attempt_num 和 wait_ms 到日志，便于事后分析。

⚠ 性能陷阱

不要对 timeout 使用固定值：大崩溃用短超时会导致频繁失败重试，小崩溃用长超时拖慢队列。
避免在重试循环内创建新的网络连接——应复用连接池并单独设置超时。

4.7 调试与验证

通过在代码中注入可配置的模拟故障（如 SIMULATE_NETWORK_DELAY=500 环境变量），验证重试间隔和超时是否符预期。以下日志摘录展示了带抖动的指数退避效果：

2025-04-12 10:01:23.456 [CRASH_UPLOAD] Attempt 0 failed (net_timeout). Wait 0.187s
2025-04-12 10:01:23.643 [CRASH_UPLOAD] Attempt 1 failed (net_timeout). Wait 0.423s
2025-04-12 10:01:24.066 [CRASH_UPLOAD] Attempt 2 succeeded. Total elapsed: 0.610s

注意：实际等待时间并非严格的 200ms、400ms、800ms，而是叠加了 0.5～1.0 之间的随机因子。