后端性能优化之服务端并发控制与限流算法 1. 问题描述 在高并发场景下，服务端资源（如CPU、内存、数据库连接等）是有限的。若请求流量超过系统处理能力，可能导致服务响应延迟飙升、资源耗尽甚至系统崩溃。 并发控制与限流 的核心目标是通过约束单位时间内的请求数量或并发线程数，保护系统稳定性，并优先保障关键业务的可用性。 2. 限流的必要性 防止资源过载 ：例如数据库连接池被占满时，新请求会阻塞或失败。 避免级联故障 ：某个服务的崩溃可能引发依赖它的其他服务雪崩。 公平性保障 ：防止恶意用户或异常流量独占系统资源。 平滑流量峰值 ：将突发流量整形为均匀请求，降低系统压力。 3. 常见限流算法及实现 3.1 固定窗口计数器（Fixed Window） 原理 ：将时间划分为固定窗口（如1秒），统计每个窗口内的请求数，超过阈值则拒绝后续请求。 示例 ： 阈值：100请求/秒 窗口： [ 0:00, 0:01)内请求数若达到100，0:00.500时刻的第101个请求被拒绝。 缺点 ： 窗口边界突刺 ：若阈值=100，0:00.900时刻涌入100请求，0:01.000时刻又涌入100请求，实际0:00.900~0:01.000这0.1秒内处理了200请求，可能压垮系统。 3.2 滑动窗口日志（Sliding Window Log） 原理 ：记录每个请求的时间戳，统计当前时间向前滑动窗口（如1秒）内的请求数量。 实现 ： 维护一个有序队列（如Redis Sorted Set），存储请求时间戳。 新请求到达时，删除早于 当前时间-窗口长度 的旧记录，检查队列长度是否超阈值。 优点 ：精准控制任意滑动窗口内的流量。 缺点 ：保存大量时间戳，内存占用高。 3.3 滑动窗口计数器（Sliding Window Counter） 原理 ：结合固定窗口与滑动窗口，将时间切分为更细粒度的子窗口（如1秒窗口拆分为10个100ms子窗口），通过子窗口计数近似滑动窗口统计。 示例 ： 主窗口=1秒，子窗口=100ms，阈值=100请求/秒。 当前时间0:00.650，统计子窗口[ 0:00.600, 0:00.650]的计数 + 前一个完整子窗口[ 0:00.500, 0:00.600 ]的计数 × 权重（滑动比例）。 优点 ：平衡精度与内存开销。 3.4 漏桶算法（Leaky Bucket） 原理 ：请求以任意速率进入桶中，桶以固定速率出水（处理请求），桶满时新请求被丢弃或排队。 实现 ： 桶容量=最大队列长度，出水速率=系统处理能力。 例如：桶容量=100，出水速率=10请求/秒，突发流量先缓存到桶中，以恒定速率处理。 优点 ：流量整形为均匀输出，保护下游系统。 缺点 ：无法应对突发流量（即使系统有空闲资源，也严格按固定速率处理）。 3.5 令牌桶算法（Token Bucket） 原理 ： 令牌以固定速率生成并存入桶中（桶有最大容量）。 请求到达时取走一个令牌，若桶空则拒绝请求。 示例 ： 令牌生成速率=10个/秒，桶容量=20。 若桶初始满，系统可瞬间处理20个请求，后续按10请求/秒平滑处理。 优点 ：允许突发流量（利用桶内积攒的令牌），同时长期平均速率受限。 4. 分布式限流挑战 单机限流仅能控制当前节点的流量，分布式环境下需全局协调。 解决方案 ： Redis + Lua脚本 ：通过原子操作统计集群请求数（如使用 INCR 和 EXPIRE 实现固定窗口）。 中间件（如Sentinel、Gateway） ：集成限流规则，动态推送配置。 一致性哈希分片 ：将用户或服务分组，每组分到特定节点限流。 5. 实践中的优化策略 动态阈值调整 ：根据系统负载（如CPU使用率）自动调整限流阈值。 分级限流 ：核心接口设置宽松阈值，非核心接口严格限制。 预热模式 ：冷启动时逐步增加令牌桶容量，避免初始流量击穿系统。 失败回退 ：限流触发时返回队列位置或重试时间，提升用户体验。 6. 总结 限流算法需根据场景权衡精度、内存开销和突发处理能力： 高精度需求 ：滑动窗口日志 平衡型 ：令牌桶（允许突发）或滑动窗口计数器 平滑流量 ：漏桶 分布式限流需依赖外部存储保证一致性，同时结合系统监控实现动态调控。