接口超时重试怎么设计才不把系统拖垮

我以前处理过一个订单服务，真正把系统压垮的不是第一次请求，而是超时后的集中重试。客户端觉得请求没返回就再发，网关也在重试，下游支付接口慢一点，几秒钟内同一笔业务被打了好几次。后来我做重试会先分清楚哪些请求能重试，哪些只能查状态。读接口可以短重试，写接口必须有幂等键和业务状态机，不能靠前端按钮防抖兜底。超时时间也不能每层都设一样，最外层要比下游长一点，不然上游刚放弃，下游还在处理。现在我会给每次请求带 trace id 和 client_request_id，把重试次数、原始请求、最终结果都打到日志里。重试策略不是越多越稳，退避、限流、熔断、查单入口都要配好，不然故障时流量会被自己放大。还有一个细节是重试预算，某个接口连续失败到一定比例后，宁愿让用户查状态，也别继续把下游打满。