Sentinel 也是阿里开源的流量控制框架吗，其限流功能基于多种经典算法实现，核心目标是防止系统因流量过载而崩溃。
常见的几种算法包括
1、滑动窗口算法
在固定窗口基础上，把每个窗口拆分成多个 "小格子"（比如 1 秒窗口拆成 10 个 0.1 秒的小格）。统计时，窗口会随着时间 "滑动"，只统计当前时间窗口内的请求数，而非固定窗口的全量计数。
1 秒窗口拆成 10 个小格，每个小格记录 0.1 秒内的请求。当时间走到 0.1 秒时，窗口滑动，去掉最旧的小格数据，加入新的小格数据。如果当前窗口内的总请求数超过阈值，就限流。
固定窗口指的是{
把时间划分为固定大小的 "窗口"（比如 1 秒一个窗口），每个窗口内设定最大请求数。
设定 "1 秒内最多 100 个请求"，第一个窗口（0-1 秒）内如果来了 120 个请求，第 101 个及之后的请求会被限流；到下一个窗口（1-2 秒）时，计数器重置，重新计数。
}
优点：
- 解决了固定窗口的 "临界问题"，精度更高
缺点：
- 窗口拆分越细（小格越多），精度越高，但计算成本略增
2、令牌桶算法
系统会按固定速率（比如每秒 100 个）往 "令牌桶" 里放令牌，每个请求需要拿到令牌才能被处理。如果桶里没令牌了，请求就被限流。桶有最大容量，令牌满了就不再生成。
令牌桶每秒生成 100 个令牌，最大存 200 个。平时请求少，桶会慢慢存满 200 个令牌；当突然来了 250 个请求时，前 200 个能拿到令牌处理，剩下 50 个因没令牌被限流；之后每秒继续生成 100 个，逐步处理后续请求。
优点：
- 既能限制长期平均速率，又能应对 "短时间突发流量"（利用桶内积累的令牌）
- 灵活性高，是实际场景中最常用的算法之一
缺点：
- 可能因 "令牌积累" 导致 "瞬时流量过载"（设定 "令牌桶容量 = 1000，每秒生成 100 个令牌"------ 如果系统长期处于低负载（比如 1 小时内几乎没请求），桶会慢慢存满 1000 个令牌。此时若突然涌入 1000 个请求，这些请求会瞬间拿完所有令牌并被处理，相当于系统在极短时间内（比如 1 秒内）要处理 1000 个请求，远超 "每秒 100 个" 的长期速率。）
3、漏桶算法
把请求比作 "水流"，系统处理能力比作 "漏桶的漏水速度"。无论流入的水流多快（突发请求），漏桶都会以固定速度 "漏水"（处理请求）。如果水流太快，桶满了就会 "溢出"（触发限流）。
漏桶的漏水速度是每秒 10 个请求（系统稳定处理能力）。如果突然来了 100 个请求，桶会先存起来，然后每秒处理 10 个；如果后续请求持续超过每秒 10 个，桶满后多余的请求会被拒绝。
优点：
- 强制限制请求处理速度，平滑流量，适合保护下游系统（如数据库）
缺点：
- 无法应对 "短时间突发流量"（即使系统能处理，也会被限流）