算法学习重试怎样避免放大故障
重试是在“这次失败可能是暂时的，并且再做一次不会造成额外副作用”两个条件都成立时才有意义。没有约束的重试会在故障时放大流量，甚至让原本可恢复的服务被二次压垮。
先判断这次请求能不能重试
网络短暂中断、连接重置和部分 5xx 可能适合重试。认证失败、参数错误、业务校验失败通常不适合。写操作需要幂等键或服务端去重机制，否则客户端不知道前一次是否已被服务端执行，重发可能造成重复扣费或重复创建。
固定间隔会让大量客户端同一时刻再次发起请求。指数退避配合随机抖动能把请求分散开，但它不是恢复保证。
delay = min(cap, base * (2 ** attempt)) delay = random.uniform(0, delay)这里的等待还要受上下文截止时间约束；如果剩余时间不够，就直接返回失败。服务端给出Retry-After时，在本地总时限允许的范围内优先遵守。
把重试放进预算里
限制总尝试次数、总等待时间和单请求成本，也要限制一段时间内的重试总量。出现连续可归因故障时，用熔断或排队保护下游，而不是让每个客户端各自坚持重试。
观察重试比例、重试放大的流量、最终成功率和请求延迟，并按错误类型拆分。阈值取决于下游容量和用户能接受的等待时间，不存在适合所有服务的一组固定参数。
