超时重试机制

本文目录导读：

1. 核心概念
2. 重试策略（关键决策点）
3. 哪些错误应该重试？
4. 重试框架对比（常见实现）
5. 高级实践与陷阱
6. 设计一个可靠的重试机制
7. 代码片段示例（Java + Resilience4j）

超时重试机制是分布式系统和网络通信中保证系统可靠性和容错性的一种关键技术，它通过在一定时间未收到响应后自动重新发起请求，来应对网络抖动、临时服务不可用等瞬时故障，从而提升系统的成功率和稳定性。

如果设计不当,它也容易引发“雪崩效应”或加重服务端的负载。

核心概念

超时（Timeout）

• 定义：从发起请求到等待响应的最大时间限制。
• 作用：防止调用方无限期地等待下游服务的响应，从而耗尽自身的线程池或连接池资源。
• 常见设置：通常会设置连接超时（建立TCP连接的时间）和读取超时（等待服务器返回数据的时间）。

重试（Retry）

• 定义：当请求失败（超时或返回可重试的错误码）后，再次发起相同的请求。
• 作用：屏蔽网络的瞬时抖动（如丢包、延迟波动）或下游服务的短暂重启/GC抖动。

重试策略（关键决策点）

固定间隔重试（Fixed Interval）

• 方式：每次重试前等待相同的时间（如 100ms）。
• 适用：对延迟不敏感，且希望快速恢复的场景。
• 风险：如果下游服务正在过载，固定时间的大量重试可能会加剧拥塞。

指数退避（Exponential Backoff）

• 方式：重试间隔逐渐增大（如第一次等待 100ms，第二次 200ms，第三次 400ms……）。
• 优点：给下游服务留出恢复时间，是推荐且最常用的策略。
• 公式：wait_time = initial_delay * (2^n)，n 是重试次数。

抖动（Jitter）

• 方式：在指数退避的基础上引入随机化（如 wait_time = random(0, base * 2^n)）。
• 原因：避免多个客户端在同一时间点同时发起重试，形成“惊群效应”导致下游再次被冲垮。

有限次数重试

• 关键：必须设置最大重试次数（通常建议 1-3 次）。
• 原因：无限重试会导致系统陷入死循环，消耗大量资源。

哪些错误应该重试？

并非所有错误都适合重试,错误分类如下：

可重试错误（Idempotent/Transient）

• 网络超时：TimeoutException（可能只是丢包/延迟，重新发起可能成功）。
• 连接断开：Connection Reset。
• 服务端异常：返回 503 Service Unavailable、500 Internal Server Error（可能是临时后端重启）。
• 限流响应：返回 429 Too Many Requests（可以等待后重试）。

不可重试错误（应该直接失败）

• 客户端错误：400 Bad Request（请求参数错误）、401 Unauthorized、403 Forbidden。
• 业务错误：更符合预期的报错（如“余额不足”、“商品已下架”）。
• 资源不存在：404 Not Found。

经验法则：如果下游返回的错误码或异常类型表明请求没有到达业务层（如连接超时、5xx 异常），则重试；如果表明业务拒绝了请求（4xx、业务错误），则不应重试。

重试框架对比（常见实现）

特性	Java (Resilience4j)	Python (Tenacity)	Go ( cenkalti/backoff )
核心注解/API	@Retry(name = "backend")	@retry 装饰器	RetryOperation
退避策略	支持固定、指数、随机、自定义	支持固定、指数、随机	支持常量、指数、混合
错误判定	基于异常类型 Predicate	基于异常类型 retry_on_exception	基于 operation 返回的错误
熔断结合	内建 CircuitBreaker	需结合其他库（如 pybreaker）	需自行实现
性能开销	低（使用 RingBuffer）	中	低

高级实践与陷阱

幂等性（Idempotency）—— 重试的前提

• 问题：如果重试请求被后端成功处理了，但返回时超时了，重试会导致重复操作（如订单重复扣款）。
• 解决方案：业务接口必须支持幂等性。
  • 全局唯一ID（Idempotent Key）：客户端生成并传入（如 UUID）。
  • 服务端去重：服务端根据 Key 检测重复请求，返回首次执行的结果。
  • 天然幂等操作：如 SET 操作、GET 查询。

超时时间与重试次数的配合

• 总调用时长 = (初始超时时间 + 每次重试间隔) * 重试次数。
• 例如：设置总超时 3 秒，单次超时 500ms，最大重试 2 次。
• 注意：不要让总超时时间超出业务可以容忍的等待极限（如对外 API 网关通常要求在 5 秒内返回）。

避免重试风暴（Retry Storm）

• 场景：服务 A 调用 B，B 调用 C，当 C 故障时，A 重试 B，B 重试 C，大量请求堆积。
• 解决方案：
  • 限制重试层级：只有最顶层服务（如网关）进行重试，内部服务尽量不重试或只重试一次。
  • 使用指数退避。
  • 引入熔断器（Circuit Breaker）：当失败率达到阈值时，直接熔断，不再重试。

备份请求（Hedged Requests）

• 思想：不是等待超时后才重试，而是在第一次请求发出后一小段时间（如 95% 的预期响应时间），如果还没有返回，立即发送第二次请求。
• 目的：降低长尾请求的延迟。
• 代价：增加下游负载（通常只用于对延迟极敏感的关键业务）。

设计一个可靠的重试机制

1. 定义明确的超时：设置连接超时和读取超时。
2. 选择退避策略：指数退避 + 随机抖动（推荐）。
3. 限制重试次数：通常不超过 3 次。
4. 正确识别可重试错误：只重试瞬态、网络级错误（5xx、超时）。
5. 保证幂等性：在关键写入接口使用 Idempotent Key。
6. 结合熔断器：防止下游长时间不可用时，无意义地重试消耗资源。

代码片段示例（Java + Resilience4j）

import io.github.resilience4j.retry.Retry;
import io.github.resilience4j.retry.RetryConfig;
import io.github.resilience4j.retry.RetryRegistry;
import java.time.Duration;
// 配置
RetryConfig config = RetryConfig.custom()
    .maxAttempts(3) // 最大重试次数（包括首次）
    .waitDuration(Duration.ofMillis(200)) // 固定等待 200ms，这里可以用指数退避替代
    .retryOnResult(response -> !response.isSuccess()) // 自定义重试条件
    .retryOnException(e -> e instanceof TimeoutException) // 只重试超时异常
    .failAfterMaxAttempts(true) // 达到次数后抛出异常
    .build();
RetryRegistry registry = RetryRegistry.of(config);
Retry retry = registry.retry("myService");
// 使用
Supplier<Response> supplier = Retry.decorateSupplier(retry, () -> myService.call());
Response result = supplier.get(); // 自动触发重试逻辑