1. 限流概述：为什么需要限流？
大家好，我是你们这次课程的主讲。在正式开始讲算法之前，我想先聊聊一个根本问题——我们为什么要限流？
说实话，我见过太多系统崩溃的案例了。有一次，一个电商平台搞秒杀活动，流量瞬间暴涨了 50 倍。结果呢？数据库连接池被打满，CPU 飙升到 99%，整个系统挂了将近 20 分钟。等恢复过来，订单已经丢了一大批。嗯，这就是典型的「没有限流」的后果。
什么是限流？
限流，说白了就是控制流量。你想想看，一个系统能处理的请求是有上限的。就像一条水管，每秒只能流过 10 升水。你非要灌 100 升，那水管肯定爆。
限流的定义其实很简单：限制单位时间内进入系统的请求数量，保证系统在安全水位下运行。
核心目标：
- 保护系统——防止突发流量打垮后端服务
- 公平分配——让每个用户都能获得合理的服务
- 成本控制——避免资源被过度消耗导致费用飙升
- 服务质量——保证核心业务的响应时间不恶化
限流 vs 熔断 vs 降级
这三个概念经常被混在一起说。我刚开始做架构的时候也搞混过。其实它们各有侧重：
| 概念 | 触发条件 | 动作 | 恢复方式 |
|---|---|---|---|
| 限流 | 请求速率超过阈值 | 拒绝部分请求 | 流量下降后自动恢复 |
| 熔断 | 错误率/延迟超过阈值 | 快速失败，停止调用 | 定时探测，成功则关闭 |
| 降级 | 系统压力过大 | 关闭非核心功能 | 手动或自动恢复 |
我习惯这么理解：限流是「挡在外面」，不让太多请求进来；熔断是「内部自保」，发现下游不行了就赶紧断开；降级是「丢卒保车」，砍掉不重要的功能保核心。
我的经验：实际项目中，这三个往往配合使用。比如先限流挡住大部分流量，如果还有异常就触发熔断，同时降级非核心接口。我曾经在一个支付系统中就是这样做的，效果很好。
限流的典型场景
哪些地方需要限流？我列几个常见的：
- API 网关——对外暴露的接口，防止恶意刷接口
- 秒杀/抢购——瞬间高并发，必须限流保护订单系统
- 第三方接口调用——对方有 QPS 限制，自己也要限流防止被封
- 数据库/缓存——防止连接池被打满
- 消息队列——控制消费速率，防止下游处理不过来
避坑指南：我曾经在一个项目中，只对读接口做了限流，写接口没做。结果突发流量全打到写接口上，数据库直接挂了。记住——所有入口都要限流，不要有侥幸心理。
限流的维度
限流不是一刀切。你可以从不同维度来限制：
- 按用户——每个用户每秒最多 10 次请求
- 按 IP——每个 IP 每分钟最多 100 次
- 按接口——某个接口总 QPS 不超过 1000
- 按服务——整个微服务实例不超过 5000 QPS
你想想看，如果不按用户限流，一个恶意用户就能把整个系统的额度占满。所以实际项目中，我通常会做多级限流：网关层按 IP 限流，业务层按用户限流，服务层按总 QPS 限流。
限流的衡量指标
怎么判断限流做得好不好？我一般看这几个指标：
| 指标 | 说明 | 理想值 |
|---|---|---|
| QPS | 每秒请求数 | 不超过系统容量的 80% |
| 拒绝率 | 被限流的请求占比 | 一般控制在 5% 以内 |
| 响应时间 | 请求处理耗时 | 限流后不应明显增加 |
| 系统负载 | CPU/内存使用率 | 保持在 70% 以下 |
核心原则：限流不是要把流量降到 0，而是让系统在可控范围内运行。我一般把阈值设在系统容量的 70%-80%，留出缓冲空间。
限流的知识体系
下面这张图，是我自己总结的限流知识体系。你可以先有个整体印象：
小结
这一章我们聊了限流的基本概念。说白了，限流就是给系统装个「水龙头」，流量大了就拧小一点。它和熔断、降级是三位一体的防护策略。
我个人觉得，理解限流的核心不在于算法多复杂，而在于什么时候限、限多少、怎么限。后面的章节，我会带着大家从最简单的计数器算法开始，一步步深入到令牌桶、漏桶这些经典算法，再到分布式限流的实战配置。
一句话记住：限流不是拒绝用户，而是保护用户能正常使用的那部分服务。宁可拒绝一部分，也不要让所有人都用不了。