滑动窗口是计算机网络中用于流量控制与拥塞控制的核心机制，也是高并发系统限流的重要算法，其本质是通过动态调整窗口大小实现数据传输效率与稳定性的平衡。
滑动窗口协议是什么？计算机网络中的流量控制核心
TCP协议为了保证数据可靠传输且不压垮接收方,引入了滑动窗口机制，接收方会通告自己的可用缓冲区大小（即窗口值），发送方据此控制已发送但未确认的数据量，这个动态范围就是“滑动窗口”。
滑动窗口如何工作？
- 发送方维护一个发送窗口,包含已发送但未确认、以及允许发送但尚未发送的数据包。
- 每收到一个确认,窗口向右滑动，新数据进入窗口被允许发送。
- 接收方通过ACK报文中的窗口字段告知剩余容量,发送方调整发送速率。
- 若窗口为0,发送方停止发送并启动持续计时器，避免死锁。
滑动窗口的核心作用
- 流量控制：防止发送方太快导致接收方缓冲区溢出，保障数据完整性。
- 累积确认：允许发送方连续发送多个数据包，等待一个确认即可滑动，提升吞吐量。
- 丢包重传触发：当收到三个重复ACK或超时，发送方缩小窗口并重传丢失段，实现拥塞控制。
滑动窗口与拥塞控制窗口的区别
- 滑动窗口（接收窗口）是接收方提供的容量上限，体现接收能力。
- 拥塞窗口是发送方根据网络拥塞程度动态调整的变量,体现网络承载能力。
- 实际发送窗口取两者较小值,行业共识认为这种双重窗口设计是TCP稳健性的关键。
滑动窗口限流机制：从网络协议到系统设计的高效演变
在分布式系统、API网关等场景中，滑动窗口限流算法借鉴了TCP窗口思想，将时间划分为多个小格子，动态统计请求次数，实现平滑限流，它比固定窗口更精准，能避免临界突发流量。
固定窗口限流的常见缺陷
- 简单计数器每分钟重置一次,若在窗口边界出现流量突增，可能导致瞬间压力翻倍。
- 统计数据显示,多数情况下固定窗口限流在实际生产中会引发“脉冲”问题，对后端服务冲击明显。
滑动窗口限流如何解决临界问题
- 将时间窗口（如1分钟）细分为多个子窗口（如6个10秒段）。
- 每个子窗口独立计数,过期后自动丢弃。
- 当前请求统计所有子窗口总和,若超过阈值则拒绝。
- 子窗口粒度越细,限流曲线越平滑，但内存开销也越大。
滑动窗口限流与令牌桶、漏桶的对比
| 算法 | 核心机制 | 适合场景 | 平滑度 | 突发处理 |
|---|---|---|---|---|
| 滑动窗口 | 基于时间片计数，总和计算 | 通用限流，尤其非固定速率场景 | 较高 | 依靠窗口粒度，可允许少量突发 |
| 令牌桶 | 按速率生成令牌，用完后等待 | 需短时突发的场景（如秒杀） | 一般 | 支持突发，令牌可积累 |
| 漏桶 | 恒定速率流出，超量丢弃 | 需严格平滑输出的场景（如数据库写入） | 极高 | 不允许突发 |
滑动窗口在应对细粒度控制时表现更好,而令牌桶更适合有突发需求的业务，这也是滑动窗口限流与令牌桶区别的核心讨论点。
实战：如何实现滑动窗口限流？
在落地时,最常见的方案是基于Redis的Sorted Set实现，每个请求的时间戳作为score，将请求ID或用户ID作为member，通过ZREMRANGEBYSCORE移除窗口外的记录，再统计当前窗口内成员数。
基于Redis的滑动窗口限流步骤
- 确定窗口大小（如1秒）和子窗口精度（如100毫秒）。
- 每次请求到来,生成当前时间戳（毫秒级）。
- 使用ZREMRANGEBYSCORE移除所有小于“当前时间戳 – 窗口大小”的成员。
- 使用ZCARD key获取当前窗口内请求总数。
- 若总数小于阈值,则执行ZADD插入当前时间戳，并设置过期时间；否则拒绝请求。
本地内存滑动窗口实现思路
- 在Java中可用ConcurrentHashMap + 时间轮盘，或使用Guava的RateLimiter（但它是令牌桶变体），若需滑动窗口，可自行维护一个循环数组，每个元素记录子窗口计数，用原子变量维护索引和总和。
- 关键操作：更新当前子窗口，移除旧子窗口计数，计算总和，需要处理并发安全，常见做法是使用分段锁或CAS。
部署时的注意事项
- 选择合适的子窗口数量：推荐10～20个，太细增加计算开销，太粗失去滑动效果。
- 对分布式限流,尽量使用Redis集群，避免单点瓶颈。
- 对于极高并发场景,可考虑本地+中心化两级限流，减少Redis调用次数。
滑动窗口面试常见问题解析
在技术面试中,滑动窗口算法面试题频繁出现，既考察计算机网络基础，也考察限流设计能力。
TCP滑动窗口大小如何动态调整？
- 接收方通过窗口字段通告,发送方在拥塞控制阶段根据慢启动、拥塞避免、快速重传等算法调整拥塞窗口，二者取小。
- 实际部署中,通常还会考虑窗口缩放因子（Window Scaling），使最大窗口超过64KB，适配高带宽场景。
滑动窗口限流如何保证高并发下的正确性？
- 核心是原子性操作：使用Redis的Lua脚本或事务，确保移除旧记录和添加新记录在同一原子操作内。
- 若使用本地内存,需配合锁或CAS，避免并发计数错误，业内专家指出，在每秒百万级请求下，建议结合本地预计算和Redis异步回写，降低延迟。
滑动窗口与固定窗口在实际选型中怎么取舍？
- 固定窗口实现简单,适合对流量精度要求不高的场景，如内部统计。
- 滑动窗口能更均匀地拦截突发流量,常用于对外API、登录接口等需要严格保护资源的场景。
- 选择时需权衡：若业务允许瞬间部分超限，固定窗口足够；若要求每秒钟都严格控制在阈值内，则必须用滑动窗口。
滑动窗口限流机制相关问题解答
Q1：滑动窗口限流一定比固定窗口限流好吗？
不一定，滑动窗口实现更复杂，需要更多内存和计算资源，如果业务对流量毛刺容忍度高，固定窗口完全够用，且性能更好，滑动窗口主要优势在于平滑边界突发，适合对限流精度要求高的场景。
Q2：TCP滑动窗口和限流滑动窗口原理本质相同吗？
机理相似，但目标不同，TCP滑动窗口控制数据包传输量，避免接收方过载；限流滑动窗口控制请求速率，保护后端服务，两者都利用“窗口”概念限定一段时间内的流量，但TCP窗口是动态协商的，而限流窗口通常由系统预设阈值。
Q3：能不能用滑动窗口限流代替流量整形中的漏桶？
不能完全替代，漏桶强制恒定输出，适合需要严格削峰填谷的场合（如数据库写入），滑动窗口允许一定突发，更适合大部分API限流场景，实际系统中常将二者组合使用，比如滑动窗口控制入口，漏桶平滑下游出口。
滑动窗口无论作为网络协议的基础机制,还是作为现代系统限流的实用算法，其核心思想都是通过动态划分区间来精确控制流量，保证了数据传输的可靠性以及服务的高可用性，理解它的原理与实现，能让你在面试和实际架构设计中都更有底气。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/541557.html
