服务端限流在应对高并发时，主要通过令牌桶、漏桶、计数器等算法，结合Redis、Nginx等中间件实现，具体方案需根据业务场景和性能要求权衡。
高并发限流方案对比：令牌桶与漏桶怎么选
令牌桶算法：应对突发流量的能手
令牌桶的核心是桶内以恒定速率放入令牌，请求消耗令牌，桶满则积累令牌，这种机制允许一定程度的突发请求，因为桶内可积累令牌，适用场景集中在需要处理瞬时尖峰流量的地方，比如API接口突发调用或秒杀准备阶段，行业共识认为，令牌桶是多数互联网公司的首选,因为它兼顾了限流和吞吐。
- 优点：允许突发，控制平局速率,灵活。
- 缺点：实现需处理令牌生成和消耗的原子性,稍复杂。
漏桶算法：强制平滑流量利器
漏桶算法将请求进入视为水倒入桶，桶底以固定速率流出，桶满则溢出拒绝，无论入口流量多大，输出都完全平滑，这对保护下游资源（如数据库写入）非常有效,Nginx的limit_req模块即基于漏桶。
- 优点：输出完全平滑,实现简单。
- 缺点：无法应对突发,不适合需要快速响应的场景。
计数器和滑动窗口：简单但需注意边界
计数器在固定窗口内计数，超过阈值则限制，但存在临界点问题：窗口边界处可能瞬间通过两倍流量，滑动窗口将窗口细分为小格子，滑动统计，缓解了边界问题,但资源开销稍大。
- 计数器实现简单,适用对精度要求不高的场景。
- 滑动窗口适用需要更精确限流的场景,常与Redis结合使用。
下表对比三种主流算法：
| 算法 | 输出速率 | 突发处理 |
实现复杂度 |
典型场景 |
|---|---|---|---|---|
| 令牌桶 | 允许突发 | 支持 | 中等 | API接口，突发流量 |
| 漏桶 | 平滑恒定 | 不支持 | 低 | 数据库流控，入侵检测 |
| 滑动窗口 | 接近平滑 | 有限支持 | 中等 | 精确计数场景 |
选择时需结合业务特征,核心是权衡突发容忍度和平滑度。
接口限流怎么做？基于Redis与Nginx的三种实现
基于Redis + Lua的计数器实现
这是最常用的分布式接口限流方案，利用Redis的INCR和EXPIRE命令，在固定窗口内计数，为保障原子性，建议使用Lua脚本封装,具体步骤：
- 定义key：接口名+用户ID或IP，设置过期时间（如1秒）。
- 使用Lua脚本执行INCR和EXPIRE,返回当前计数。
- 判断计数是否超过阈值,超过则返回限流提示。
该方案能支撑每秒数万次请求，但需要注意Redis单点故障和集群模式下key的分布，多数情况下，配合Redis Sentinel即可保证高可用。
基于Redis的令牌桶限流实现
在Redis中维护令牌桶状态，用Lua脚本实现令牌生成和消耗,核心逻辑：
- 读取桶内令牌数、上次更新时间。
- 根据时间间隔计算应补充令牌数,更新令牌数。
- 消耗一个令牌,写回Redis。
Redis单线程特性配合Lua避免了竞争，但需要自定义key结构，桶容量和填充速率可配置，业内专家指出，高并发下建议使用Redis Pipeline或批量操作减少网络开销。
Nginx内置限流模块配置
Nginx的ngx_http_limit_req_module基于漏桶，可实现单机接口限流,配置示例：
- 在http块定义limit_req_zone：$binary_remote_addr作为key，共享内存zone=one:10m，rate=30r/s。
- 在location块应用limit_req zone=one burst=20 nodelay。
burst=20允许突发20个请求，nodelay表示尽快处理，还可用limit_conn限制并发连接，该方案对运维友好，无需代码改动，但仅适用于单机,多个Nginx节点需配合一致性哈希或全局限流。
分布式限流实践：应对秒杀场景的解决思路
分布式限流的核心挑战
分布式限流需要跨多个节点协调计数，面临一致性和性能的矛盾，严格一致性会引入高延迟，影响用户体验，多数场景下采用最终一致性,允许少量误差。
- 共识：限流是概率性措施,不必百分百精确。
- 关键：选择合适的限流粒度（用户、接口、IP）和存储介质。
基于Redis Cluster的全局限流
Redis Cluster天然支持分布式，但需注意Redis的批量操作Lua脚本在集群中可能跨slot，导致错误，解决方案是保证key的散列在同一slot，例如用哈希标签,具体步骤：
- 使用Redis的INCR、Lua脚本实现计数器或令牌桶。
- 配置Redis Sentinel或Cluster保证高可用。
- 设置合理的超时时间和重试策略。
据统计，相当一部分互联网公司使用Redis作为分布式限流的主要存储,因其成熟和生态。
网关层限流与Sentinel框架
网关层（如Zuul、Kong）可以统一限流，避免后端耦合，Alibaba开源的Sentinel提供了丰富的限流、熔断、降级功能，支持实时监控，配置流控规则时，可以针对QPS、线程数、冷启动等。
- 实操：引入Sentinel依赖，定义资源，配置规则（如QPS=100）。
- 规则动态生效,无需重启应用。
- 结合控制台Dashboard,可直观看到流量波动。
Sentinel官方文档指出，它支持千兆级QPS,非常适合高并发场景。
限流与降级、熔断的配合
限流是主动控制，降级是当系统压力过大时暂时关闭非核心功能，熔断是当服务调用失败率过高时切断流量，三者常组合使用，例如在秒杀系统里，先限流，对超出部分立即返回失败,同时触发熔断保护下游。
- 典型策略：动态调整限流阈值,利用监控数据反馈调整。
- 行业共识认为，限流、降级、熔断是微服务高可用三大支柱,缺一不可。
限流方案的本质是资源保护：令牌桶和漏桶是理论基石，Redis和Nginx是落地利器，分布式限流则需在一致性与性能间作取舍。
高并发限流常见问题
高并发限流怎么选择算法？
主要看业务是否有突发流量，如果允许短时间突发（如API接口），令牌桶最合适，如果需要严格平滑输出（如写入数据库），漏桶更稳妥，简单场景可选用计数器加滑动窗口，实现成本低，推荐对核心接口使用令牌桶,非核心使用漏桶或计数器。
Nginx限流和Redis限流哪个更好？
Nginx限流基于单机，性能极高，适合入口层快速拒绝，Redis限流能做分布式全局控制，但会增加网络开销，通常架构是：Nginx做第一层限流，Redis做后端服务层限流，兼顾效率与公平，如果业务规模不大,单机Nginx足以应对。
分布式限流如何保证数据一致性？
分布式限流的一致性与性能存在Trade-off，多数情况下，采用Redis原子操作（Lua）保证强一致性，但会牺牲部分吞吐，如果对精度要求不高，可以使用本地计数器+定期同步的方案，实现最终一致性，实际部署中，可接受5%-10%的误差,通过合理设置阈值避免过载。