Daily Study

更新: 5/28/2025 字数: 0 字时长: 0 分钟

Daily Plan

#todo

计数器算法、漏桶算法、令牌桶算法

固定窗口计数器 (Fixed Window Counter):
- 原理： 在固定的时间窗口内（例如每秒），维护一个计数器。每当有请求进入，计数器加1。如果计数器超过预设的阈值，则拒绝新的请求。时间窗口结束后，计数器清零。
- 优点： 实现简单。
- 缺点： 临界问题/突刺流量问题。例如，限流100 QPS，如果在窗口1的最后1ms涌入100个请求，然后在窗口2的开始1ms又涌入100个请求，那么在2ms内实际通过了200个请求，可能超出系统承受能力。
滑动窗口计数器 (Sliding Window Counter):
- 原理： 将时间窗口划分为更小的多个子窗口（格子），每个子窗口维护一个独立的计数器。随着时间的推移，窗口整体向右滑动。当前窗口的总请求数是所有子窗口计数器之和。当新的请求进入时，当前子窗口计数器加1，如果总数超过阈值则拒绝。
- 优点： 相比固定窗口，滑动窗口能更平滑地控制流量，有效缓解临界突刺问题。
- 缺点： 实现比固定窗口略复杂，仍可能存在一定程度的突刺（取决于子窗口的粒度）。

原理： 将请求想象成流入漏桶的水。漏桶以恒定的速率漏出（处理）请求。如果流入速率过快，导致桶内水量（请求队列）超过桶的容量，则新流入的水（请求）会溢出（被拒绝）。
核心特性：
- 强制请求以平滑、恒定的速率被处理。
- 能够有效地整形流量 (Traffic Shaping)，削平突发流量。
优点： 控制流量速率非常平滑，能有效保护下游系统。
缺点：
- 无法有效处理有意义的突发流量。即使系统有处理能力，由于漏出速率固定，突发请求也可能因为桶满而被丢弃或排队过久。
- 不适合需要快速响应且允许一定突发的场景。

原理： 系统以一个恒定的速率往桶里放入令牌。每个进入的请求都需要从桶中获取一个令牌，获取到令牌才能被处理。如果桶中没有令牌，则请求需要等待（直到有新令牌放入）或被拒绝。桶本身有容量上限，多余的令牌会溢出。

核心特性：
- 允许一定程度的突发流量。只要桶内有足够的令牌，突发请求可以被立即处理。
- 最大突发量取决于桶的容量。
- 长期来看，平均处理速率受令牌生成速率的限制。
优点： 既能限制平均速率，又能允许短时间的突发流量，应用更广泛，尤其适合需要快速响应的场景。
缺点： 实现比计数器略复杂。如果桶容量设置过大，可能瞬间将压力传导给下游。

位置： 在发起请求的客户端或调用下游服务的服务内部。
目的：
- 自我保护： 防止自身应用因无节制地调用下游服务而耗尽资源（如线程、连接池）。
- 保护下游： 主动减少对下游服务的冲击，避免打垮依赖的服务，做个“好公民”。
- 快速失败： 在请求发出前就进行限制，避免不必要的网络开销和等待。
实现方式：
- 应用内部的限流组件（如Guava RateLimiter, Sentinel等客户端SDK）。
- 通过代理层（如Nginx、Envoy等部署在调用方侧的Sidecar）进行出流量控制。
常用算法： 令牌桶 通常更适合调用方，因为它允许一定突发，同时控制平均速率。计数器也可以使用。

位置： 在提供服务的应用本身或其入口处（如API网关、负载均衡器）。
目的：
- 自我保护： 防止自身服务因流量过大而被压垮，保证核心服务的稳定性和可用性。
- 公平性： 防止部分用户/客户端占用过多资源，影响其他用户。
- 成本控制： 限制资源消耗，避免不必要的成本支出。
实现方式：
- API网关层： 如Nginx, Kong, APISIX, Spring Cloud Gateway等，可以针对路由、用户、IP等维度进行限流。
- 应用层内部： 在代码中嵌入限流逻辑（如使用Sentinel, Resilience4j等库），可以更精细地控制具体接口或方法的调用频率。
- 中间件/基础设施： 一些负载均衡器、WAF (Web Application Firewall) 也提供限流功能。
常用算法： 令牌桶（允许突发）、漏桶（平滑流量，保护核心资源）、滑动窗口计数器（实现相对简单且效果不错）都非常常见。具体选择取决于对突发流量的处理策略和保护目标。