第2章：限流降级的核心思想与适用场景
限流和降级，这两个词听起来挺像的。很多新手容易搞混。
我刚开始带团队的时候，有个同事问我：“限流和降级不就是一回事吗？都是不让请求过去呗。” 我当时笑了笑，说：“你想想看，一个是拦住，一个是放弃，本质逻辑完全不同。”
这一章，我们就来把这两个概念彻底掰扯清楚。我会结合我在几个高并发项目里的真实经历，帮你建立一套清晰的判断标准。
2.1 限流：把流量控制在系统能承受的范围内
限流，说白了就是主动拒绝超出预期的请求。
你的系统能力是有限的。比如你的数据库每秒只能处理 1000 个查询。如果突然来了 5000 个请求，你不拦着，数据库就会挂掉。限流就是在这 5000 个请求到达数据库之前，先扔掉 4000 个。
核心目标：保护系统不被突发流量冲垮，保证核心服务的可用性。
我在项目中遇到过这样一个场景：某次大促活动，零点刚过，流量瞬间飙升到平时的 50 倍。如果没有限流，网关层直接被打穿，所有服务都会雪崩。嗯，那场面，想想都后怕。
2.1.1 限流的典型适用场景
- 秒杀/抢购活动：瞬间涌入的流量远超系统处理能力，必须在前置网关层做限流。
- API 接口保护：防止外部恶意调用或爬虫程序耗尽你的资源。
- 数据库/缓存保护：避免突发查询打垮底层存储。
- 第三方接口调用：对方有 QPS 限制，你必须在客户端做限流，否则会被封。
我的习惯：限流尽量做在最外层，比如 Nginx 层或 API 网关层。越早拦截，对后端资源的消耗越小。
2.2 降级：在压力下主动放弃非核心功能
降级和限流不一样。降级不是“拦住请求”，而是主动关闭一些不重要的功能，把资源腾出来给核心功能。
举个例子：你做了一个电商网站。用户下单是核心功能，而“查看历史订单”是非核心功能。当系统压力过大时，你可以暂时关闭“查看历史订单”功能，返回一个“系统繁忙，请稍后再试”的提示。这样，数据库的连接数就省下来了，下单功能就能继续正常运行。
核心目标：牺牲非核心功能，保障核心功能的可用性和响应速度。
我曾经在一个项目中犯过错误。当时我们做了一个“个性化推荐”模块，觉得它很重要。结果流量一上来，推荐模块占用了大量 CPU，导致下单接口超时。后来我们才意识到，对于用户来说，“能下单”比“看到什么推荐”重要得多。从那以后，我就把推荐模块标记为“可降级”了。
2.2.1 降级的典型适用场景
- 非核心业务接口：比如日志上报、用户行为分析、消息推送。
- 耗时较长的计算任务：比如报表生成、数据导出。
- 依赖的外部服务：当第三方服务响应变慢或不可用时，主动降级，避免自身线程被阻塞。
- 读多写少的场景：可以降级为读取缓存中的旧数据，放弃实时查询。
注意：降级不是永久关闭。你需要设计一个恢复机制。当系统压力下降后，要能自动或手动把降级的功能恢复回来。
2.3 限流 vs 降级：一张表看懂区别
很多同学会混淆这两个概念。我整理了一张对比表，你一看就明白了。
| 对比维度 | 限流 | 降级 |
|---|---|---|
| 核心动作 | 拒绝请求 | 关闭功能 |
| 触发条件 | 流量超过预设阈值 | 系统资源紧张或依赖故障 |
| 影响范围 | 部分用户请求被拒绝 | 所有用户的部分功能不可用 |
| 恢复方式 | 流量下降后自动恢复 | 需要手动或自动恢复功能 |
| 典型实现 | 令牌桶、漏桶、计数器 | 开关配置、熔断器 |
| 用户体验 | 直接返回“请求过于频繁” | 返回“功能暂不可用”或降级数据 |
你看，限流是对“量”的控制，降级是对“质”的取舍。两者相辅相成，并不冲突。
2.4 限流降级的整体决策流程
在实际项目中，我们不会单独使用限流或降级。通常是一套组合拳。下面这张图，是我自己总结的决策流程。
这个流程很简单：
- 先限流：请求进来，先判断是否超过限流阈值。超了就直接拒绝，不废话。
- 再降级：没超限流阈值，但系统资源已经紧张了，或者某个依赖服务挂了。这时候就要判断是否触发降级条件。
- 正常处理：既没超限流，也没触发降级，那就正常处理。
我的建议：限流和降级的判断顺序不要搞反。先限流，再降级。因为限流是“硬性拦截”，成本最低。降级是“软性妥协”，需要业务逻辑配合。
2.5 什么时候该用限流？什么时候该用降级？
这个问题，我经常被问到。其实判断标准很简单，就两句话：
- 如果问题是“流量太大”：用限流。比如秒杀、爬虫攻击。
- 如果问题是“资源不够”或“依赖挂了”：用降级。比如数据库连接池满了、第三方接口超时。
当然，更多时候是两者结合。比如双十一大促，你既要限流（控制总流量），又要降级（关闭非核心功能）。
避坑指南：我曾经在一个项目里，把降级当限流用。当时觉得“功能降级了，流量自然就小了”。结果呢？降级确实关闭了功能，但请求量一点没少，网关层还是被打穿了。后来我才明白，降级只能释放后端资源，不能减少网络连接数。要减少连接数，必须靠限流。
2.6 本章小结
限流和降级，是高并发系统的两把保护伞。限流负责“挡”，降级负责“让”。两者目标一致：保证系统在极端压力下，依然能提供核心服务。
记住我给你的那个决策流程图。以后遇到高并发场景，先想清楚：我是要限流，还是要降级，还是两个都要？