C# Polly Hedging策略方法 C#如何发送多个请求并选择最快的响应

polly 的 hedging 策略是在主请求超时或失败前主动发起备份请求，任一成功即取消其余请求并采用其响应；它解决单点延迟抖动问题，要求 httpclient 支持 cancellationToken 且 api 幂等。

什么是 Polly 的 Hedging 策略

Hedging 不是并发发多个请求然后“等全部返回再挑最快的”，而是：在主请求响应超时或失败前，主动发起一个或多个备份请求；一旦任一请求成功返回，就立即取消其余未完成的请求，并使用该响应。它解决的是“单点延迟抖动”问题，比如某个服务实例临时卡顿、网络短暂拥塞。

注意：Hedging 依赖底层 HttpClient 支持取消（即使用 CancellationToken），且目标 API 必须是幂等的——因为可能有多个请求实际到达服务端。

如何配置 AddHedgingPolicy 并集成到 HttpClient

从 Polly v8 开始，Hedging 是独立策略，需显式添加。它不和 Retry 或 Timeout 自动组合，必须手动链式调用。

• 必须先配置 Timeout 策略作为 hedging 的触发条件（即“主请求多久没回就发备份”）
• hedgingDelay 参数决定备份请求的延迟时间（例如 TimeSpan.FromMilliseconds(100)），不是并发发起，而是错峰降低雪崩风险
• maxHedgedAttempts 包含原始请求，所以设为 3 表示最多总共尝试 3 次（1 次原 + 2 次备份）
• 必须用 AddPolicyHandler 注册到 IHttpClientBuilder，不能只靠 AddTransientHttpErrorPolicy

示例注册代码：

services.AddHttpClient<MyApiClient>()     .AddPolicyHandler(Policy.TimeoutAsync<HttpResponseMessage>(TimeSpan.FromSeconds(3)))     .AddPolicyHandler(Policy.HedgingAsync<HttpResponseMessage>(         maxHedgedAttempts: 3,         hedgingDelay: TimeSpan.FromMilliseconds(100),         onHedging: (ev) => {             Console.WriteLine($"Hedging attempt {ev.AttemptNumber} for {ev.OriginalRequest.RequestUri}");         },         policy: Policy.HandleResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)                     .WaitAndRetryAsync(new[] { TimeSpan.Zero })     ));

Hedging 下的响应取消与资源清理关键点

很多人以为只要用了 Hedging 就自动取消其他请求——其实不然。Polly 仅负责调用 HttpClient.SendAsync(..., cancellationToken) 时传入的 token，是否真正中断连接，取决于：

• HttpClient 实例是否复用（推荐用 IHttpClientFactory，避免 socket 耗尽）
• 目标服务器是否尊重 Connection: close 或 TCP RST
• .NET 版本：.NET 5+ 对 HttpClient 取消支持更可靠；.NET Core 3.1 及以前在某些 TLS 场景下可能无法及时中断
• 你自己的 HttpRequestMessage 是否设置了 Content 且未设置 Headers.ContentLength？流式上传内容可能导致取消滞后

建议在业务代码中始终显式检查 response.IsSuccessStatusCode，并用 response.Content.ReadAsStringAsync() 后尽快释放，不要长期持有 HttpContent 流。

为什么不用 Task.WhenAny 手写“最快响应”逻辑

直接用 Task.WhenAny 发多个 HttpClient.SendAsync 看似简单，但会踩一堆坑：

• 没有内置超时控制，需额外套 Task.WhenAny + Task.Delay，逻辑复杂且易漏 cancel
• 无法统一处理重试、熔断、降级等策略，和 Polly 生态割裂
• 所有请求都真实发出，无延迟错峰，可能把下游打挂（尤其非幂等操作）
• 无法感知哪个是“主请求”，日志、指标、链路追踪难以对齐
• 手动取消时，HttpClient 的 Dispose 和 socket 复用行为不可控，容易引发 SocketException 或连接泄漏

Hedging 是 Polly 对这类场景的封装抽象，它把“延迟发起 + 取消剩余 + 结果选择”收拢成可配置、可观测、可组合的行为。手写反而更容易出错，也难维护。

真正需要关注的，是 hedging 延迟值怎么定、最大尝试次数是否合理、以及后端接口是否真的幂等——这些比“怎么写语法”重要得多。