高并发接口的限流熔断降级与隔离

当一个依赖变慢时，最危险的反应是让所有请求继续等待并不断重试。稳定性设计要先限制故障传播，再决定哪些功能可以牺牲。

超时必须小于上游预算

如果用户接口总预算是 500ms，内部调用不能都设置 500ms。需要给序列化、排队和返回预留时间，并把多个下游调用的预算拆开。

总预算 500ms
  网关与排队 50ms
  商品服务 180ms
  价格服务 120ms
  返回与日志 50ms
  余量 100ms

超时应该在每一层传递，避免下游继续工作而上游已经放弃。

重试要有边界

只有明确可重试的错误才重试，例如连接失败和临时过载。使用指数退避加随机抖动，限制总次数和总时长。写操作没有幂等键时，重试可能制造重复订单。

熔断和舱壁

熔断器按失败率、超时率或连续错误数进入打开状态，经过冷却时间再半开探测。探测请求要小，成功后逐步恢复，而不是一次放开全部流量。

舱壁隔离通过独立线程池、连接池或并发信号量，让支付、搜索和报表不会抢同一组资源。每个依赖都应有最大并发和等待队列长度。

降级不是返回空白

降级策略应该提前和产品确认：

依赖	可接受降级
推荐	返回热门列表
评论	只读缓存，暂时关闭发布
实时价格	返回最近一次有效价格并标记时间
通知	进入队列，稍后发送

降级响应要带可观察的原因码，不能让前端误以为业务已经成功。

演练与恢复

每月模拟一次 Redis 延迟、下游 5xx、消息积压和数据库只读，检查熔断是否打开、告警是否触达、人工开关是否有效。故障结束后要逐步恢复流量，并核对降级期间产生的补偿任务。

稳定性不是一组中间件开关，而是把每类故障的影响范围、用户体验和恢复动作写成可执行的运行手册。