某微服务调用下游库存服务时出现短暂超时。开发人员准备让所有失败请求立即无限重试，架构师认为这样可能在下游刚刚变慢时进一步放大压力，形成重试风暴。较合理的改进措施是（）。
重试可以提高短暂故障下的成功率，但无限、立即、同步重试会把原本已经变慢的下游打得更慢，甚至引发级联故障。合理做法是限制重试次数，采用指数退避和随机抖动分散重试压力，并结合超时、熔断、降级、限流和监控告警。
选项分析
正确。它同时控制重试次数、重试节奏和故障扩散，是更完整的稳定性设计。
错误。删除日志不能解决故障，还会让定位问题更困难。
错误。立即无限重试很容易造成重试风暴和级联故障。
错误。失败请求集中同步写入且不限速，可能进一步拖垮数据库。
本题为什么容易错
很多同学把“失败了就重试”当成标准答案。重试本身没有错，但必须有边界。没有次数上限、没有退避、没有抖动、没有超时和熔断的重试，可能比不重试更危险。
简短答案
为什么服务异常时不能让所有请求立即无限重试，正确答案是 A（设置重试次数上限，并配合指数退避、随机抖动、超时、熔断和降级策略）。重试可以提高短暂故障下的成功率，但无限、立即、同步重试会把原本已经变慢的下游打得更慢，甚至引发级联故障。合理做法是限制重试次数，采用指数退避和随机抖动分散重试压力，并结合超时、熔断、降级、限流和监控告警。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 设置重试次数上限，并配合指数退避、随机抖动、超时、熔断和降级策略 | 本题正确答案 | 正确。它同时控制重试次数、重试节奏和故障扩散，是更完整的稳定性设计。 | 看到题干核心场景时优先联想到它 |
| 删除所有日志，避免看到错误 | 本题干扰项 | 错误。删除日志不能解决故障，还会让定位问题更困难。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 让客户端每 1 毫秒无限重试，直到下游恢复 | 本题干扰项 | 错误。立即无限重试很容易造成重试风暴和级联故障。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 把所有失败请求都同步写入同一张数据库大表，不做限速 | 本题干扰项 | 错误。失败请求集中同步写入且不限速，可能进一步拖垮数据库。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 删除所有日志，避免看到错误：错误。删除日志不能解决故障，还会让定位问题更困难。
- 让客户端每 1 毫秒无限重试，直到下游恢复：错误。立即无限重试很容易造成重试风暴和级联故障。
- 把所有失败请求都同步写入同一张数据库大表，不做限速：错误。失败请求集中同步写入且不限速，可能进一步拖垮数据库。
知识点详解
重试风暴常见于分布式系统：下游服务变慢后，上游大量请求失败并同步重试，导致下游压力继续增加，最终把局部故障放大成系统性故障。指数退避通过逐步拉长重试间隔降低压力，随机抖动避免大量请求在同一时刻重试。它们通常还要和幂等设计、超时控制、熔断降级、限流和监控配合，才能形成稳定性闭环。考题如果写“所有客户端同时重试”“失败后立即无限重试”“下游服务已经超时”，就要警惕这不是在考积极性，而是在考你会不会避免把故障扩大。真实系统里，重试策略还要区分读请求和写请求，写请求尤其要先确认幂等性。
备考速记
速记：重试要有刹车。次数有限、间隔退避、时间打散、故障熔断。
微服务稳定性在微服务稳定性场景中的作用
微服务稳定性在本题中的核心价值，是解决“某微服务调用下游库存服务时出现短暂超时。开发人员准备让所有失败请求立即无限重试，架构师认为这样可能在下游刚刚变慢时进一步放大压力，形成重试风暴。较合理的改进措施是（）”这个场景问题。复习时不要只背选项名称，还要理解它为什么适用于该场景，以及它能解决哪类安全、流程或管理问题。
同类题怎么考
- 给出微服务稳定性场景，判断应该选择哪个概念、工具、协议或管理过程。
- 考查微服务稳定性的作用，要求从四个相近选项中找出最符合题干目标的一项。
- 把微服务稳定性和删除所有日志，避免看到错误、让客户端每 1 毫秒无限重试，直到下游恢复、把所有失败请求都同步写入同一张数据库大表，不做限速放在一起考，重点看适用场景是否一致。
- 题干通常会出现一个关键动作或目标，先定位关键词，再回到选项逐一排除。
微服务稳定性在系统架构设计师软考中的考法
软考选择题通常不会只考概念定义，还会把微服务稳定性放到微服务稳定性场景中，要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时，先抓住题干中的业务场景，再看哪个选项最能解决该场景下的核心问题。
解题思路
这题看起来问重试，其实问的是系统保护。老师讲微服务时会提醒：下游已经喘不过气了，上游如果立刻一起重试，相当于再补几拳。指数退避让重试间隔逐步拉长，随机抖动避免请求同一时刻再次拥上去；熔断和降级则保护核心链路。
考点定位
架构稳定性题不要把重试当万能药。重试看幂等、次数上限、退避策略、超时和熔断，核心是避免把故障放大。
易错提醒
- 对非幂等接口盲目重试，造成重复扣款、重复扣库存或重复创建订单。
- 所有客户端固定间隔同时重试，形成同步冲击。
- 只加重试，不加超时、熔断、限流、监控和降级。
备考提示
- 系统架构设计师复习稳定性时，把超时、重试、熔断、限流、降级、隔离放在一组比较。
- 看到瞬时故障可以重试，但看到下游持续变慢，要警惕重试风暴。
- 架构题里的好答案通常不是一个技术点，而是一组有边界的保护措施。
你可能还想了解
- 为什么服务异常时不能让所有请求立即无限重试？
- 微服务稳定性是什么？
- 微服务稳定性在系统架构设计师考试中怎么考？
- 系统架构设计师微服务稳定性题怎么理解？
- 重试风暴怎么避免怎么考？
- 指数退避和随机抖动怎么考？
本文小结
本题核心考点是微服务稳定性在微服务稳定性场景中的判断和应用。遇到类似题目时，先看题干描述的目标，再判断哪个选项最符合场景；本题应选择 A（设置重试次数上限，并配合指数退避、随机抖动、超时、熔断和降级策略）。