网络笔记：超时与重试：为什么会放大流量

本文深入解析超时与重试机制如何导致流量放大，以及如何通过合理的策略避免这一问题。

1. 为什么超时 + 重试会放大流量

一次请求慢 → 触发重试 → 并发上升 → 队列更长 → 更慢 → 更多超时（正反馈）。

1.1 流量放大的正反馈循环

flowchart TD
  A[请求慢] --> B[触发超时]
  B --> C[发起重试]
  C --> D[并发上升]
  D --> E[队列更长]
  E --> F[响应更慢]
  F --> A
  
  Note over A,F: 正反馈循环

1.2 重试放大的示例

sequenceDiagram
  participant C as Client
  participant S as Server

  C->>S: Request 1
  Note over S: 处理慢...
  Note over C: 超时
  
  C->>S: Request 1 (重试 1)
  C->>S: Request 2
  Note over S: 队列堆积
  
  Note over C: 再次超时
  C->>S: Request 1 (重试 2)
  C->>S: Request 2 (重试 1)
  C->>S: Request 3
  
  Note over C,S: 流量被放大

1.3 流量放大倍数

假设：

• 原始 QPS: 1000
• 超时率: 5%
• 重试次数: 3 次
• 重试成功率: 50%

流量放大 = 1000 + 1000 × 5% × 3 × 50% = 1075 QPS

如果重试没有退避，所有重试同时发生，可能导致流量瞬间放大数倍。

flowchart TD
  A[原始流量] --> B[超时请求]
  B --> C[重试流量]
  C --> D[总流量]
  
  E[1000 QPS] --> F[50 超时]
  F --> G[150 重试]
  G --> H[1150 总流量]
  
  Note over E,H: 流量放大 15%

2. 工程解法（优先级顺序）

1. 限流/熔断：先阻止雪崩扩散
2. 退避 + 抖动：避免同步重试
3. 幂等与去重：避免重试产生副作用

2.1 限流/熔断

flowchart TD
  A[请求] --> B{限流检查}
  B -->|通过| C{熔断检查}
  B -->|拒绝| D[返回限流错误]
  
  C -->|关闭| E[正常处理]
  C -->|打开| F[返回熔断错误]
  
  E --> G[处理请求]
  G --> H{成功?}
  H -->|是| I[更新熔断状态]
  H -->|否| I

2.2 退避 + 抖动

sequenceDiagram
  participant C as Client
  participant S as Server

  C->>S: Request 1
  Note over C: 超时
  
  Note over C: 等待 100ms + 随机抖动
  C->>S: Request 1 (重试 1)
  Note over C: 再次超时
  
  Note over C: 等待 200ms + 随机抖动
  C->>S: Request 1 (重试 2)
  
  Note over C,S: 指数退避 + 抖动避免同步

2.3 退避策略对比

flowchart TD
  A[退避策略] --> B[固定间隔]
  A --> C[指数退避]
  A --> D[指数退避 + 抖动]
  
  B --> E[简单但易同步]
  C --> F[减少重试但可能延迟高]
  D --> G[最佳实践]

2.4 幂等与去重

flowchart TD
  A[请求] --> B{幂等检查}
  B -->|已处理| C[返回结果]
  B -->|未处理| D[处理请求]
  D --> E[标记已处理]
  E --> F[返回结果]
  
  G[去重机制] --> H[请求 ID]
  H --> I[去重表]
  I --> J[避免重复处理]

3. 观测指标

超时率、重试率、入队等待时间、P99、以及重试导致的额外 QPS。

3.1 关键指标

flowchart TD
  A[观测指标] --> B[超时率]
  A --> C[重试率]
  A --> D[入队等待时间]
  A --> E[P99 延迟]
  A --> F[额外 QPS]
  
  B --> G[超时请求数 / 总请求数]
  C --> H[重试请求数 / 总请求数]
  D --> I[队列等待时间]
  E --> J[尾延迟]
  F --> K[重试导致的流量增加]

3.2 指标监控

sequenceDiagram
  participant App as Application
  participant Monitor as Monitor

  App->>App: 记录请求
  App->>App: 检测超时
  App->>App: 发起重试
  App->>Monitor: 上报指标
  
  Monitor->>Monitor: 计算超时率
  Monitor->>Monitor: 计算重试率
  Monitor->>Monitor: 计算额外 QPS
  Monitor->>Monitor: 告警

4. 实际案例

4.1 案例：同步重试导致的流量放大

问题：系统在高峰期出现流量突然放大 3 倍

分析：

• 超时率 10%
• 所有重试同时发生（无退避）
• 导致流量瞬间放大

优化：

• 实现指数退避
• 添加随机抖动
• 添加限流

结果：

• 流量放大降到 15%
• 系统稳定性提升

4.2 案例：重试导致的数据重复

问题：重试导致数据重复写入

分析：

• 请求没有幂等性
• 重试时重复处理
• 导致数据重复

优化：

• 添加请求 ID
• 实现去重机制
• 确保幂等性

结果：数据重复问题解决

5. 设计原则与最佳实践

5.1 设计原则

1. 先限流后重试：避免雪崩
2. 退避 + 抖动：避免同步
3. 幂等 + 去重：避免副作用

5.2 最佳实践

flowchart TD
  A[超时重试最佳实践] --> B[合理设置超时]
  A --> C[实现退避策略]
  A --> D[添加抖动]
  A --> E[确保幂等]
  A --> F[实现去重]
  A --> G[监控指标]
  
  B --> H[基于 P99 设置]
  C --> I[指数退避]
  D --> J[随机抖动]
  E --> K[请求 ID]
  F --> L[去重表]
  G --> M[及时告警]

6. 小结

超时与重试是网络编程中的常见模式，但不合理的重试策略会导致流量放大，形成正反馈循环。通过限流/熔断、退避+抖动、幂等+去重等策略，可以有效避免这一问题。

核心要点：

• 超时 + 重试会形成正反馈循环，导致流量放大
• 限流/熔断是防止雪崩的第一道防线
• 退避 + 抖动可以避免同步重试
• 幂等 + 去重可以避免重试副作用

优化策略：

1. 先限流/熔断，再重试
2. 实现指数退避 + 随机抖动
3. 确保请求幂等性
4. 监控关键指标（超时率、重试率、额外 QPS）