Go net/http 如何实现受控请求对冲并取消慢副本

如果下游接口没有报错，只是偶尔慢到拖住整条请求链，单纯增加失败重试并不能解决问题：重试通常要等到超时或错误之后才开始，而尾延迟请求仍然占着用户的等待时间。对于可以安全重复读取的请求，可以在达到一个延迟阈值后启动有限的第二个副本，谁先成功就采用谁，并立即取消其余副本。

本文用 Go 标准库实现这个模式，不依赖第三方韧性库。示例只针对 GET 这类没有业务写入副作用的请求；扣款、创建订单、发送消息等操作即使使用 POST，也不能因为变慢就自动复制。

官方地址：https://pkg.go.dev/net/http

官方地址：https://pkg.go.dev/context

先把请求对冲和失败重试分开

失败重试处理的是“这次尝试已经失败”，请求对冲处理的是“这次尝试还活着，但超过了正常延迟”。对冲的第二个请求不是无上限复制，而是受三个预算约束：等待多久才启动、最多允许多少副本、整个用户请求还剩多少时间。

例如正常 P95 是 120 毫秒，可以把对冲延迟先设为 120 毫秒。第一份请求在阈值内返回时不产生额外流量；只有第一份仍未完成时才启动第二份。延迟值应来自自己的延迟分布和下游容量，不能照抄某个固定数字。

用 Context 管住总预算和副本生命周期

Go 官方文档说明，出站请求的 Context 会影响建立连接、发送请求以及读取响应头和响应体的完整生命周期；派生 Context 被取消时，所有副本都应收到同一个停止信号。因此要从入口 Context 派生一个总超时，再为整组副本准备一个可主动取消的子 Context。

这里的总超时不是每个副本各自拥有的超时。若每个副本都重新获得完整 500 毫秒，两个副本可能把用户请求拖到 1 秒以上。总 Context 让所有副本共享最后期限，cancel 则负责在首个结果到达后回收剩余工作。

实现一个有上限的对冲 GET

下面的函数最多启动两个 GET 副本。结果通道使用带缓冲容量，避免获胜结果已经返回后，慢副本在收到取消时还卡在发送结果的位置。每个副本都负责关闭自己的响应体；调用方只读取获胜副本的响应内容。

package hedge

import (
	"context"
	"fmt"
	"io"
	"net/http"
	"time"
)

// HedgeGet 只适合没有写入副作用、可以安全重复的 GET 请求。
func HedgeGet(parent context.Context, client *http.Client, url string,
	totalTimeout, hedgeAfter time.Duration) ([]byte, error) {
	// 总超时由整组副本共享，避免每个副本各自获得完整预算。
	ctx, cancel := context.WithTimeout(parent, totalTimeout)
	defer cancel() // 释放计时器，并在返回时取消尚未结束的副本

	type result struct {
		body []byte
		err  error
	}
	// 通道容量覆盖两个副本，慢副本取消后仍能安全交付错误结果。
	results := make(chan result, 2)
	start := func() {
		go func() {
			req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
			if err != nil {
				results = 300 {
				results 

这个实现的关键不是“并发越多越快”，而是把副本数量固定为两个，并让第二份只在第一份超过阈值或快速失败时启动。真实项目还应给结果增加请求 ID、尝试编号和取消原因，便于判断是原请求获胜，还是对冲副本获胜。

处理全部失败、取消和响应体

当两个副本都返回错误时，函数返回先观察到的错误；如果总 Context 先结束，则返回 context deadline exceeded 或父 Context 的取消原因。业务层可以据此决定是否向上游返回超时，而不要把一个已经取消的慢副本误记成新的下游故障。

http.Client.Do 成功后一定会得到非空的 Response.Body，调用方必须关闭它。对冲会增加响应体处理路径，尤其要避免先把大响应全部读入内存再决定胜负；生产代码可以在协议允许时限制读取大小，并在选定结果后尽快取消另一个副本。

ctx, cancel := context.WithTimeout(parent, 500*time.Millisecond)
defer cancel() // 退出当前操作时释放 Context 相关资源

req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
	return err
}
resp, err := client.Do(req)
if err != nil {
	// 取消或截止时间触发时，优先保留 Context 的错误语义。
	return err
}
defer resp.Body.Close() // 读取完成后归还连接资源
// 只有在状态码和响应内容都可接受时，才把这次尝试当作胜出。

哪些请求不能直接做对冲

对冲会真实发出两次请求，所以“首个响应返回”不等于“另一份请求已经没有副作用”。GET、HEAD 或明确设计为幂等读取的内部查询通常更容易满足前提；POST、PATCH、扣款、发券、创建订单、发送消息等写操作默认禁止自动对冲。

如果业务确实需要对写操作做重试或副本控制，应先使用幂等键、服务端去重和明确的提交状态查询，把“重复到达”变成可判断的同一次业务操作。仅仅把请求方法改成 GET，或在客户端收到首个结果后调用 cancel，都不能撤销已经抵达服务端的写入。

还要留意请求体是否可重放。本文示例使用无请求体的 GET；带流式 Body 的请求不能简单复制同一个 Reader。即使拥有 GetBody，也必须确认服务端、代理和业务语义都允许重复发送。

如何设定对冲延迟和上线观察指标

先从访问日志或分布式追踪中得到同一接口的延迟分布，再选择一个只覆盖最慢少数请求的阈值。阈值过短会把正常请求也复制，阈值过长则几乎没有降低尾延迟的机会。不要把来源文章中的示例数值当成自己的默认配置。

上线后至少记录四类指标：对冲触发率、副本获胜比例、被取消副本的平均运行时间、每个逻辑请求产生的实际下游请求数。若副本获胜率很低但额外流量很高，说明阈值或下游容量不合适；若取消后的服务端仍持续执行，则需要检查服务端是否正确接收并遵守请求 Context。

小结

Go 请求对冲的落点是三个控制点：用延迟阈值决定是否启动第二份，用总 Context 约束整组请求，用取消信号回收未获胜副本。它适合可安全重复的慢读取，不是所有 HTTP 请求的通用加速开关。先确认幂等性和下游容量，再用少量副本、清晰指标和总截止时间把额外流量关在预算内。

常见问题

请求对冲和重试有什么区别？重试通常在失败后再次尝试；对冲是在原请求尚未失败但超过延迟阈值时并发启动副本。

为什么必须共享一个总超时？否则每个副本都可能获得完整时长，多个副本叠加后会突破用户请求的实际等待预算。

首个响应返回后可以立刻忽略其他副本吗？不能。应先取消共享 Context，并让每个副本关闭自己的响应体，否则会留下连接、goroutine 或服务端工作。

POST 是否永远不能对冲？不是 HTTP 方法单独决定，而是业务副作用决定。没有幂等键和服务端去重时，POST 写操作应默认禁止复制。