企业官网建设流程全解析

超时重试的边界设计

以下数字是便于理解放大效应的示例，不是事故统计。重试次数和超时值需要按幂等性、下游容量和错误预算分别配置。

超时重试会在下游变慢时放大请求量，这是高并发系统中需要重点防范的机制风险。

以订单查询为例：下游响应超过客户端超时阈值后，多个上游若同时重试，额外请求会继续占用连接和数据库资源；资源越紧张，越多请求超时，形成反馈回路。放大倍数取决于重试次数、并发量和取消是否生效，不能预先写成固定数字。

因此，重试应仅用于可安全重放的调用，并配合退避、抖动、限额和熔断。数据库压力升高时，优先拒绝或降级非核心请求，而不是继续累积等待。

为什么简单的 fixed-retry 是高并发系统的毒药

几乎所有刚接触高可用架构的工程师，都写过类似这样的重试代码：

// 典型的反面教材：固定间隔硬重试 for (int i = 0; i < 3; i++) { try { return callDownstreamService(); } catch (Exception e) { Thread.sleep(100); // 固定等待 100ms } }

这种简单的fixed-retry（固定时间间隔重试）在高并发线上环境简直就是毒药。

当下游服务因为资源紧张出现瞬间拥塞时，所有的上游重试请求都会在完全相同的间隔时间（如 100ms）再次密集砸向下游。这在微服务领域被称为惊群重试风暴（Retry Storm）。下游服务本来正在努力消化积压的请求，结果每一波固定间隔的重试流量就像海啸一样周期性打来，彻底剥夺了下游自我恢复的可能。

指数退避、全抖动（Full Jitter）与重试预算（Retry Budget）代码实现

要消除重试风暴，必须在重试机制中引入指数退避（Exponential Backoff）、全抖动随机化（Full Jitter）以及重试预算（Retry Budget）。

1. 指数退避：每次重试的等待时间翻倍（如 100ms -> 200ms -> 400ms），给下游留出指数级的喘息窗口。
2. 全抖动（Full Jitter）：在退避区间内加入完全随机的抖动（如sleep = random(0, min(max_backoff, base * 2^attempt))），把密集的重试流量在时间轴上均匀打散，彻底规避峰值重叠。
3. 重试预算（Retry Budget）：在一个窗口内（如过去 1 分钟），重试请求的数量不能超过总请求数量的 10%。一旦超过这个预算上限，说明下游已经发生系统级瘫痪，后续失败请求立刻拒绝重试，直接快速失败（Fail Fast）。

以下是一段采用 Java / Resilience4j 逻辑编写的防重试风暴算法实现：

package com.highavailability.retry; import lombok.extern.slf4j.Slf4j; import java.util.concurrent.ThreadLocalRandom; import java.util.concurrent.atomic.AtomicInteger; @Slf4j public class SafeRetryExecutor { private final int maxRetries; private final long baseBackoffMs; private final long maxBackoffMs; // 重试预算计数器：过去窗口内的总请求与重试数 private final AtomicInteger totalRequests = new AtomicInteger(0); private final AtomicInteger retryRequests = new AtomicInteger(0); public SafeRetryExecutor(int maxRetries, long baseBackoffMs, long maxBackoffMs) { this.maxRetries = maxRetries; this.baseBackoffMs = baseBackoffMs; this.maxBackoffMs = maxBackoffMs; } public <T> T executeWithBudget(CheckedSupplier<T> supplier) throws Exception { totalRequests.incrementAndGet(); int attempt = 0; while (true) { try { return supplier.get(); } catch (Exception e) { attempt++; // 1. 超过最大重试次数，终止 if (attempt > maxRetries) { log.warn("已达到最大重试次数 {}，放弃重试", maxRetries); throw e; } // 2. 检查重试预算：重试比例超过 10% 则拒绝重试，防雪崩 if (!checkRetryBudget()) { log.error("重试预算已被超用 (Retry Budget Exceeded)！强制快速失败，保护下游服务"); throw e; } // 3. 计算带 Full Jitter 的退避等待时间 long sleepTime = calculateFullJitterSleep(attempt); log.info("第 {} 次请求失败，触发 Full Jitter 避让，等待 {} ms", attempt, sleepTime); retryRequests.incrementAndGet(); Thread.sleep(sleepTime); } } } /** * 计算 Full Jitter 指数退避时长 */ private long calculateFullJitterSleep(int attempt) { // temp = min(maxBackoff, base * 2^attempt) long temp = Math.min(maxBackoffMs, baseBackoffMs * (1L << attempt)); // sleep = random(0, temp) return ThreadLocalRandom.current().nextLong(0, temp + 1); } /** * 重试预算检查：重试总数不能超过总请求数的 10% */ private boolean checkRetryBudget() { int total = totalRequests.get(); int retries = retryRequests.get(); if (total < 100) { return true; // 样本量太小，放行 } return ((double) retries / total) <= 0.10; } @FunctionalInterface public interface CheckedSupplier<T> { T get() throws Exception; } }

熔断器与网关层重试策略的联动隔离

防重试风暴不能仅靠客户端的自觉，还必须在微服务网关层建立强有力的隔离防线。

在 Spring Cloud Gateway 或 Nginx/Envoy 网关层，必须做到以下三点联动：

1. 只在幂等接口上重试：严禁在POST（非幂等提交）接口上开启网关自动重试，仅允许在GET或带有唯一幂等 Token（Idempotency Token）的接口上启用。
2. 重试状态码严格限制：只对502 Bad Gateway、503 Service Unavailable或网络 Read Timeout 响应进行重试；对于4xx客户端错误或500 Internal Error（通常是业务代码抛出 NullPointerException）绝对不重试。
3. 断路器状态联动：当 Sentinel / Resilience4j 断路器进入 Open（开启）或 Half-Open（半开）状态时，网关立刻屏蔽所有上游重试机制，直接透传错误给客户端。

超时与重试就像高可用架构中的一把双刃剑。用得好可以抹平网络的瞬间抖动，用得不好就是压垮下游系统的最后一根稻草。给重试加上预算拦截、加上指数随机退避、加上幂等隔离，系统才真正具备了抵御风暴的抗打击能力。