某只读查询服务部署了多个等价副本，绝大多数请求 80 ms 内完成，但少量请求会拖到 2 秒。团队计划使用 Hedged Request 降低尾延迟。较稳妥的做法是（）。
对冲请求不是一开始就复制所有流量，而是在主请求超过选定延迟阈值后，再向等价副本补发少量幂等请求，使用最先完成的有效结果并取消其余请求。这样可削减尾延迟，同时控制额外负载。
选项分析
错误。全量同时复制会近乎成倍增加负载，慢请求若不取消还会继续消耗资源。
正确。延迟触发、等价副本、幂等操作、先到先用和及时取消共同构成受控对冲。
错误。非幂等写操作可能产生重复扣款或重复订单，不能直接套用读请求的对冲方法。
错误。无限等待只会放大尾延迟和资源占用，不能绕开异常慢副本。
本题为什么容易错
最容易犯的错是把对冲请求当成普通重试。普通重试往往在失败后再发；对冲可能在原请求仍执行时补发，因此更要控制触发比例、并发量和取消机制。
简短答案
少量副本响应异常缓慢时，对冲请求应该怎样发送，正确答案是 B（主请求超过合理延迟阈值仍未返回时，再向另一副本发送一次幂等查询，取先返回结果并取消其余请求）。对冲请求不是一开始就复制所有流量，而是在主请求超过选定延迟阈值后，再向等价副本补发少量幂等请求，使用最先完成的有效结果并取消其余请求。这样可削减尾延迟，同时控制额外负载。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 每个请求一开始就同时复制到所有副本，且永不取消较慢请求 | 本题干扰项 | 错误。全量同时复制会近乎成倍增加负载，慢请求若不取消还会继续消耗资源。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 主请求超过合理延迟阈值仍未返回时，再向另一副本发送一次幂等查询，取先返回结果并取消其余请求 | 本题正确答案 | 正确。延迟触发、等价副本、幂等操作、先到先用和及时取消共同构成受控对冲。 | 看到题干核心场景时优先联想到它 |
| 对扣款、下单等写操作无条件并发发送多份请求 | 本题干扰项 | 错误。非幂等写操作可能产生重复扣款或重复订单，不能直接套用读请求的对冲方法。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 把客户端超时时间改为无限长，等待最慢副本返回 | 本题干扰项 | 错误。无限等待只会放大尾延迟和资源占用，不能绕开异常慢副本。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 每个请求一开始就同时复制到所有副本，且永不取消较慢请求：错误。全量同时复制会近乎成倍增加负载，慢请求若不取消还会继续消耗资源。
- 对扣款、下单等写操作无条件并发发送多份请求：错误。非幂等写操作可能产生重复扣款或重复订单，不能直接套用读请求的对冲方法。
- 把客户端超时时间改为无限长，等待最慢副本返回：错误。无限等待只会放大尾延迟和资源占用，不能绕开异常慢副本。
知识点详解
Hedged Request 常用于多副本、幂等读取且尾延迟明显的系统。调用方先发送主请求，若在基于历史分位数或动态策略确定的阈值内未完成，再向另一个独立副本补发请求。最先得到的有效响应被采用，其他请求应取消或丢弃。设计时必须限制对冲比例与并发，确认副本故障域相对独立，并监控额外负载、取消效果和P99改善；在容量已经饱和时盲目对冲可能让尾延迟更差。
备考速记
先给主请求机会，尾部太慢再补一枪；幂等、限量、先到先用、及时取消。
Hedged Request 在幂等查询场景中的作用
Hedged Request在本题中的核心价值，是解决“某只读查询服务部署了多个等价副本，绝大多数请求 80 ms 内完成，但少量请求会拖到 2 秒。团队计划使用 Hedged Request 降低尾延迟。较稳妥的做法是（）”这个场景问题。复习时不要只背选项名称，还要理解它为什么适用于该场景，以及它能解决哪类安全、流程或管理问题。
同类题怎么考
- 根据少量异常慢请求选择尾延迟优化手段。
- 判断哪些读写操作适合或不适合并发对冲。
Hedged Request 在系统架构设计师软考中的考法
软考选择题通常不会只考概念定义，还会把Hedged Request放到幂等查询场景中，要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时，先抓住题干中的业务场景，再看哪个选项最能解决该场景下的核心问题。
解题思路
这题先看延迟分布：大多数请求很快，只有少数被慢副本拖住，说明问题在尾巴而非平均吞吐。合理做法不是让每个请求都双发，而是先给主请求一个正常完成机会；超过接近高分位延迟的阈值，再补发一份到另一副本。谁先返回就用谁，并尽快取消另一份。这样额外请求只占少量，B 才把收益和代价都交代清楚。
考点定位
对冲请求优化的是少数慢请求造成的尾延迟。它用少量额外工作换响应时间，前提是操作可安全重复且系统仍有容量余量。
易错提醒
- 阈值设得低于正常抖动，导致大部分请求都被复制。
- 两个副本实际共享同一瓶颈，补发请求反而加重拥塞。
- 收到首个成功结果后不取消或忽略迟到请求，资源仍被占用。
备考提示
- 用P50、P95、P99画一条延迟分布，理解尾延迟为何不能只看平均值。
- 把超时重试、投机执行和对冲请求按触发时机与并发关系做对照。
你可能还想了解
- 对冲请求和超时重试有什么区别？
- 对冲请求为什么只适合幂等操作？
- 对冲阈值应该根据平均延迟还是高分位延迟设置？
本文小结
对冲请求在主查询超过合理延迟阈值后向等价副本补发幂等请求，取最先成功结果并取消其余请求。它能降低尾延迟，但必须限制额外负载。