降级与限流

当依赖不可用或过载时，牺牲非核心功能 保住核心路径——这叫 降级（Degradation）。限流（Rate Limiting） 则在入口 拒绝超额流量，防止系统被压垮。

学习目标

• 掌握功能开关、缓存兜底、429 限流三种手段
• 设计 CodeRoadMap 可降级的功能边界
• 对照 Gateway 限流见 sc-gateway

降级策略

策略	做法	用户体验
返回缓存	读路径走 Redis / 本地缓存	数据可能旧，但页面可用
默认值	fallback 返回占位内容	缺头像、缺进度条
功能开关	feature flag 关非核心模块	评论关闭，课程仍可读
异步化	非关键写进队列稍后处理	通知延迟，订单仍创建

模式层见 ip-circuit fallback 设计。

限流层次

[CDN / WAF]        ← 防 DDoS（若有）
      │
[宝塔 Nginx]       ← limit_req_zone
      │
[Gateway / backend]← Resilience4j RateLimiter / Bucket4j
      │
[MySQL]            ← max_connections 最后一道

429 Too Many Requests 应带 Retry-After，避免客户端立刻重试（rel-retries）。

CodeRoadMap 降级示例

tracks API 正常路径：
  GET /tracks → backend → MySQL

降级路径（MySQL 慢/熔断 OPEN）：
  GET /tracks → 读本地缓存 / 静态 JSON 快照
  POST 进度   → 503 +「稍后再试」（写不可降级则明确失败）

写路径降级更危险——宁可失败也别丢数据；读路径优先保体验。

与 SLO 的关系

非核心功能降级后，核心 SLI（如课程列表可用）仍应达标；错误预算花在「主动降级」好过「全站 500」（rel-slo）。

练习

• 列出 CodeRoadMap 三个可降级、两个不可降级的功能
• 设计 tracks 列表的缓存 TTL 与失效策略
• 说明 429 与 503 对客户端重试行为的影响

小结

降级保核心体验；限流保系统不被流量打死。 下一课：事务与一致性。