2. 限流基础理论：限流的目的与作用、常见限流算法原理对比
2.1 限流的目的与作用
在金融API系统中，限流（Rate Limiting）是一种通过控制单位时间内请求量的技术手段，防止系统被突发流量冲垮，保障核心服务的稳定性与公平性。
核心目的： 保护系统资源，确保高可用性，而非拒绝用户。
| 作用维度 | 具体说明 | 金融场景示例 |
|---|---|---|
| 防止过载 | 避免单点资源（CPU、内存、数据库连接）耗尽 | 行情推送接口突发10倍流量，限流保护后端计算集群 |
| 公平调度 | 确保所有用户/租户获得平等的服务配额 | 不同机构API Key共享网关，按权重分配请求额度 |
| 成本控制 | 限制非核心或高成本请求的调用频率 | 风控查询接口按调用量计费，限流防止恶意刷单 |
| 安全防护 | 减缓DDoS攻击、暴力破解、爬虫等恶意行为 | 登录接口连续失败5次后触发限流，阻断暴力枚举 |
| 削峰填谷 | 平滑突发流量，让系统以恒定速率处理请求 | 交易结算日大量订单涌入，限流后排队异步处理 |
实践要点： 限流不是万能的。它无法区分正常用户与恶意流量，通常需要与认证、鉴权、熔断、降级等机制配合使用。
2.2 常见限流算法原理对比
业界主流限流算法包括：计数器、滑动窗口、漏桶、令牌桶。下面通过原理说明、SVG流程图和对比表格进行详细分析。
2.2.1 计数器算法（固定窗口）
将时间划分为固定大小的窗口（如1秒），每个窗口内维护一个计数器。请求到达时计数器加1，若计数器超过阈值则拒绝请求，窗口结束后计数器重置。
2.2.2 滑动窗口算法
将固定窗口细分为多个小格子（如1秒窗口分为10个100ms格子），每个格子独立计数。窗口随着时间推移向前滑动，统计当前窗口内所有格子的累计值，超过阈值则拒绝。
2.2.3 漏桶算法
将请求比作水，系统是一个固定容量的桶，底部以恒定速率漏水（处理请求）。当桶满时，新请求被丢弃。漏桶强制输出速率恒定，适合需要严格平滑流量的场景。
2.2.4 令牌桶算法
系统以恒定速率向桶中放入令牌，每个请求需要消耗一个令牌才能被处理。桶有容量上限，令牌积累不超过上限。令牌桶允许一定程度的突发流量（桶内积攒的令牌可被快速消耗），是业界最常用的限流算法。
2.3 四种算法对比总结
| 算法 | 核心机制 | 输出速率 | 突发处理 | 内存开销 | 适用场景 |
|---|---|---|---|---|---|
| 计数器 | 固定时间窗口内计数 | 不保证恒定 | 差（临界突变） | 低（1个计数器） | 简单限流、非关键路径 |
| 滑动窗口 | 细分窗口滑动统计 | 较平滑 | 较好（消除临界） | 中（N个子计数器） | 需要精确统计的场景 |
| 漏桶 | 固定容量桶 + 恒定漏水 | 严格恒定 | 差（强制削峰） | 低（队列+定时器） | 数据库写入、消息队列 |
| 令牌桶 | 恒定放令牌 + 请求消耗 | 平均恒定 | 好（允许突发） | 低（计数器+定时器） | 金融API网关、Web服务 |
金融API推荐： 令牌桶算法是金融网关限流的首选方案。它既能保证长期平均速率，又能应对行情波动、交易高峰等突发流量，且实现简单、性能开销低。滑动窗口常用于需要精确统计QPS的监控场景。
2.4 算法选型决策树
在实际项目中，可根据以下条件快速选择限流算法：
- 是否需要严格恒定输出速率？ → 是 → 漏桶（如：批量结算、数据同步）
- 是否需要支持突发流量？ → 是 → 令牌桶（如：行情查询、交易下单）
- 是否需要精确统计窗口内请求分布？ → 是 → 滑动窗口（如：QPS监控、费用计算）
- 是否仅需简单粗暴的限制？ → 是 → 计数器（如：非核心接口、临时限流）