一、什么是限流？
通俗说，限流就是给系统“设个门槛”，限制单位时间内的请求数量，避免太多请求同时涌入把系统压垮。
比如一家奶茶店，最多同时招待10位客人点单，再多就会让制作台、服务员忙不过来，导致所有人都等很久甚至订单出错。限流就像门口的保安，超过10人就拦住，让后面的人排队，保证店里能正常运转。
对系统来说，限流能保护服务器、数据库等资源不被过载，让系统在可控范围内稳定工作。
二、常见的限流算法有哪些？怎么实现的？
不同场景需要不同的限流策略，常见的算法有4种，核心都是控制“单位时间内的请求数”，但思路各有侧重：
1. 固定窗口限流（又称“计数器限流”）
思路：把时间切成固定的“窗口”（比如1秒一个窗口），每个窗口里最多允许N个请求，超过就拒绝。
举例：规定1秒内最多100个请求。
0-1秒内，第101个请求来的时候，直接拒绝。到1秒整，计数器清零，1-2秒又能接受新的100个请求。
优点：简单好实现，用一个计数器+时间戳就行。
缺点：有“窗口临界问题”。比如第1秒的最后100毫秒来了100个请求，第2秒的前100毫秒又来100个请求，这200毫秒内实际有200个请求，超过了1秒100的限制，可能压垮系统。
2. 滑动窗口限流
思路：把固定窗口拆成更小的“子窗口”，每次时间推进，窗口像“滑动”一样移动，综合多个子窗口的请求数来判断是否限流。
举例：1秒的窗口拆成10个100毫秒的子窗口，每个子窗口最多10个请求。
当判断当前是否允许请求时，会计算最近1秒内（即当前子窗口+前9个子窗口）的总请求数，超过100就拒绝。这样能避免固定窗口在临界时间点的突发流量问题。
优点：比固定窗口更精确，能平滑流量。
缺点：子窗口拆分越细，计算越复杂，需要记录每个子窗口的请求数，消耗更多内存。
3. 漏桶算法
思路：把请求想象成“水流”，系统是一个“漏桶”——水流进桶里，桶以固定速度向外漏水（处理请求）。如果进水太快，桶满了就会溢出（拒绝请求）。
举例：系统每秒最多处理10个请求（漏水速度固定），如果突然来了20个请求，桶里先存10个，剩下10个直接拒绝，然后每秒处理1个存着的请求。
优点：能强行控制请求的处理速度，避免系统被突发流量冲击（不管进来多快，处理速度始终平稳）。
缺点：不够灵活。比如系统偶尔能处理更快的请求，但漏桶会强行把多余的请求拒掉，可能浪费资源。
4. 令牌桶算法
思路：系统会按固定速度往“令牌桶”里放令牌（比如每秒放100个），请求来了必须拿到令牌才能被处理。如果桶里没令牌，请求就被拒绝或排队。
举例：桶最多存100个令牌，每秒新增10个。
平时请求少，令牌会攒在桶里（最多100个）。突然来了150个请求，桶里的100个令牌能先处理100个，剩下50个等新令牌（每秒来10个，5秒后处理完）。
优点：既控制了平均速度，又能应对短时间的突发流量（利用桶里攒的令牌），比漏桶更灵活，实际中用得最多（比如API网关限流常用）。
总结
限流的核心是“保护系统不被过载”，本质是控制单位时间的请求量。固定窗口简单但有临界问题，滑动窗口更精确但复杂；漏桶强制平稳处理，令牌桶能应对突发流量（更常用）。
Java里可以用Guava的RateLimiter（基于令牌桶）快速实现限流，也可以自己基于Redis（用计数器+过期时间）实现分布式限流，核心都是上述算法的思路落地。