如何设计限流器从固定窗口到分布式部署的完整指南system-design-notes 第4章【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes 是《System Design Interview》一书的配套笔记项目第 4 章带你从零开始设计一个限流器Rate Limiter它会先讲清限流为什么重要再逐一拆解令牌桶、漏桶、固定窗口、滑动窗口等 5 种限流算法最后给出基于 Redis 的分布式限流架构。本文按新手视角重述这一章帮你快速掌握限流器的完整设计思路。一、为什么要做限流先明确限流器的三大价值限流器是控制客户端或服务请求速率的系统组件常见场景包括限制发帖次数、注册频率、奖励领取等。它的核心收益有三点收益说明️ 防 DoS 攻击拦截过量调用避免资源被耗尽其 降低成本减少无效请求降低服务器开销⚖️ 防止过载过滤过量请求稳定服务端性能本章的核心需求是准确的请求限流、最小化延迟、低内存占用、支持分布式部署、清晰的异常提示如返回 429和高容错能力。二、限流器部署在哪里三种位置怎么选限流器可以放在客户端、服务端或中间件层。客户端方案不可靠用户可绕过服务端方案更可控而API 网关/中间件是最灵活的位置——在这里做统一限流微服务无需各自实现。选型建议摘自章节笔记评估现有技术栈选择高效的实现位置根据业务需求选择限流算法后文详解若使用微服务架构优先考虑在 API 网关层限流资源有限时可直接采用成熟的商业方案。三、5 种主流限流算法对比从固定窗口到滑动窗口1. 令牌桶Token Bucket支持突发流量的经典方案桶里按固定速率放入令牌每个请求消耗一个令牌令牌足够则放行否则丢弃。它实现简单、内存占用低且天然支持流量突发桶里积攒的令牌可以一次性消费。关键参数桶容量支持多大的突发和填充速率长期限流速率需要仔细调优。2. 漏桶Leaking Bucket输出速率绝对平滑漏桶用 FIFO 队列存储请求队列未满则入队然后以固定速率处理桶满则直接丢弃。它能让流出速率保持恒定非常适合下游处理能力有限的场景。缺点突发流量会让后面的请求排队等待延迟升高。3. 固定窗口计数Fixed Window Counter最简单但有边界缺陷把时间切成固定区间如每秒、每分钟每个窗口用一个计数器限制请求数实现极其简单、效率高。缺陷在于窗口边界假设限制为每分钟 10 次请求用户在 2:00:50 发 10 个、又在 2:01:10 发 10 个每个窗口内都没超限但短短 20 秒内实际通过了 20 个请求——是配额的两倍。4. 滑动窗口日志Sliding Window Log精确但费内存为每个请求记录时间戳判断时只统计当前时间 - 窗口长度以内仍有效的记录过期记录删除。这是最精确的方案但每个请求都要占一条记录高 QPS 下内存消耗很大。5. 滑动窗口计数Sliding Window Counter工程上最常用的折中它用加权求和近似滑动窗口当前窗口计数 上一窗口计数 × 时间占比。以限 5 次/分钟为例当前时刻处于当前分钟 30% 处则估算值 当前窗口 3 次 上一窗口 5 次 × 70% ≈ 6.5 次已超限则拒绝。优点内存友好、能平滑流量尖峰代价是近似值不够严格。五种算法一句话速查算法精确度内存突发支持适用场景令牌桶中低✅ 好允许突发的大部分 API漏桶中中❌ 平滑下游处理慢、需匀速固定窗口低极低❌简单场景、粗粒度限流滑动窗口日志高高❌QPS 不高但要求精确滑动窗口计数中高低部分大规模生产环境首选四、分布式限流架构基于 Redis 的完整部署方案单机限流在多节点部署后会遇到竞态条件各节点各算各的总请求量失控。章节给出的生产级方案是核心设计要点数据存储在内存缓存如 Redis中计数操作快且天然支持多节点共享请求流程客户端 → 限流中间件 → 查缓存中的规则Workers 加载 查 Redis 计数器 → 放行到 API Servers 或被限流被限流的请求有两条出路直接丢弃或放入消息队列延迟处理限流规则由独立 Workers 加载并缓存规则变更无需重启服务。分布式一致性技巧在 Redis 中使用锁、Lua 脚本保证判断扣减原子执行或有序集合ZSet来消除竞态。性能优化与监控多数据中心部署降低跨节点查询延迟采用最终一致性模型做计数器同步限流场景允许少量偏差定期分析限流数据验证算法有效性并动态调整规则。五、本章小结与延伸阅读限流器设计的核心链路是明确限流目标 → 选对部署位置推荐 API 网关/中间件→ 按业务特性选算法突发友好选令牌桶、平滑输出选漏桶、生产环境常用滑动窗口计数→ 用 Redis 等共享存储解决分布式问题 → 通过监控持续调优规则。 想深入原始笔记章节原文在 04. Rate Limiter/Readme.md全书章节目录见 Readme.md。限流器是分布式系统的入门基石掌握它之后建议接着学习第 5 章一致性哈希05. Consistent Hashing/Readme.md与第 6 章 KV 存储设计把分布式三板斧补齐。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何设计限流器：从固定窗口到分布式部署的完整指南（system-design-notes 第4章）
如何设计限流器从固定窗口到分布式部署的完整指南system-design-notes 第4章【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notessystem-design-notes 是《System Design Interview》一书的配套笔记项目第 4 章带你从零开始设计一个限流器Rate Limiter它会先讲清限流为什么重要再逐一拆解令牌桶、漏桶、固定窗口、滑动窗口等 5 种限流算法最后给出基于 Redis 的分布式限流架构。本文按新手视角重述这一章帮你快速掌握限流器的完整设计思路。一、为什么要做限流先明确限流器的三大价值限流器是控制客户端或服务请求速率的系统组件常见场景包括限制发帖次数、注册频率、奖励领取等。它的核心收益有三点收益说明️ 防 DoS 攻击拦截过量调用避免资源被耗尽其 降低成本减少无效请求降低服务器开销⚖️ 防止过载过滤过量请求稳定服务端性能本章的核心需求是准确的请求限流、最小化延迟、低内存占用、支持分布式部署、清晰的异常提示如返回 429和高容错能力。二、限流器部署在哪里三种位置怎么选限流器可以放在客户端、服务端或中间件层。客户端方案不可靠用户可绕过服务端方案更可控而API 网关/中间件是最灵活的位置——在这里做统一限流微服务无需各自实现。选型建议摘自章节笔记评估现有技术栈选择高效的实现位置根据业务需求选择限流算法后文详解若使用微服务架构优先考虑在 API 网关层限流资源有限时可直接采用成熟的商业方案。三、5 种主流限流算法对比从固定窗口到滑动窗口1. 令牌桶Token Bucket支持突发流量的经典方案桶里按固定速率放入令牌每个请求消耗一个令牌令牌足够则放行否则丢弃。它实现简单、内存占用低且天然支持流量突发桶里积攒的令牌可以一次性消费。关键参数桶容量支持多大的突发和填充速率长期限流速率需要仔细调优。2. 漏桶Leaking Bucket输出速率绝对平滑漏桶用 FIFO 队列存储请求队列未满则入队然后以固定速率处理桶满则直接丢弃。它能让流出速率保持恒定非常适合下游处理能力有限的场景。缺点突发流量会让后面的请求排队等待延迟升高。3. 固定窗口计数Fixed Window Counter最简单但有边界缺陷把时间切成固定区间如每秒、每分钟每个窗口用一个计数器限制请求数实现极其简单、效率高。缺陷在于窗口边界假设限制为每分钟 10 次请求用户在 2:00:50 发 10 个、又在 2:01:10 发 10 个每个窗口内都没超限但短短 20 秒内实际通过了 20 个请求——是配额的两倍。4. 滑动窗口日志Sliding Window Log精确但费内存为每个请求记录时间戳判断时只统计当前时间 - 窗口长度以内仍有效的记录过期记录删除。这是最精确的方案但每个请求都要占一条记录高 QPS 下内存消耗很大。5. 滑动窗口计数Sliding Window Counter工程上最常用的折中它用加权求和近似滑动窗口当前窗口计数 上一窗口计数 × 时间占比。以限 5 次/分钟为例当前时刻处于当前分钟 30% 处则估算值 当前窗口 3 次 上一窗口 5 次 × 70% ≈ 6.5 次已超限则拒绝。优点内存友好、能平滑流量尖峰代价是近似值不够严格。五种算法一句话速查算法精确度内存突发支持适用场景令牌桶中低✅ 好允许突发的大部分 API漏桶中中❌ 平滑下游处理慢、需匀速固定窗口低极低❌简单场景、粗粒度限流滑动窗口日志高高❌QPS 不高但要求精确滑动窗口计数中高低部分大规模生产环境首选四、分布式限流架构基于 Redis 的完整部署方案单机限流在多节点部署后会遇到竞态条件各节点各算各的总请求量失控。章节给出的生产级方案是核心设计要点数据存储在内存缓存如 Redis中计数操作快且天然支持多节点共享请求流程客户端 → 限流中间件 → 查缓存中的规则Workers 加载 查 Redis 计数器 → 放行到 API Servers 或被限流被限流的请求有两条出路直接丢弃或放入消息队列延迟处理限流规则由独立 Workers 加载并缓存规则变更无需重启服务。分布式一致性技巧在 Redis 中使用锁、Lua 脚本保证判断扣减原子执行或有序集合ZSet来消除竞态。性能优化与监控多数据中心部署降低跨节点查询延迟采用最终一致性模型做计数器同步限流场景允许少量偏差定期分析限流数据验证算法有效性并动态调整规则。五、本章小结与延伸阅读限流器设计的核心链路是明确限流目标 → 选对部署位置推荐 API 网关/中间件→ 按业务特性选算法突发友好选令牌桶、平滑输出选漏桶、生产环境常用滑动窗口计数→ 用 Redis 等共享存储解决分布式问题 → 通过监控持续调优规则。 想深入原始笔记章节原文在 04. Rate Limiter/Readme.md全书章节目录见 Readme.md。限流器是分布式系统的入门基石掌握它之后建议接着学习第 5 章一致性哈希05. Consistent Hashing/Readme.md与第 6 章 KV 存储设计把分布式三板斧补齐。【免费下载链接】system-design-notesNotes of the book System Desgin Interview - An Insiders Guide项目地址: https://gitcode.com/GitHub_Trending/sy/system-design-notes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考