ASP.NET Web API 在面对突发流量时，仅靠固定阈值的限流策略经常出现两种问题：要么阈值设置过低导致正常请求被误杀，要么阈值过高让瞬时流量打垮下游服务。ROC（Rate of Change，变化率）关注的不是当前请求总数，而是单位时间内请求数量的增长速度。比如正常流量下每秒请求数从 100 匀速增长到 120，ROC 值是 20；如果下一秒突然跃升到 800，ROC 会瞬间变大，系统可以在请求总数尚未突破上限前就启动保护。本文通过自定义消息处理器和滑动时间窗口，在 C# 中实现一个可动态调整阈值的 ROC 限流组件。
一、固定阈值限流的盲区与 ROC 的引入
常见的固定窗口计数、令牌桶和漏桶算法，本质上都是围绕“数量上限”来做文章。以固定窗口为例，假设某个下单接口每秒最多允许 200 次请求，那么在窗口周期内，只要计数没有达到 200，所有请求都会被放行。问题在于，计数器的增长速度完全被忽略了。一个正常的预热过程可能是每秒从 50 到 80 再到 120，而一次恶意爬虫或脚本攻击可能在 0.2 秒内就打满 200 次。两者的最终计数相同，但对后端服务的冲击完全不同。固定阈值限流只有在计数触顶后才开始拒绝，此时数据库连接池可能已经被拖垮。
ROC 的思路来自信号处理和金融指标中的动量分析，它衡量的是序列的一阶差分，即当前速率与前一个采样周期速率的差值。在 Web API 场景下，我们可以把每个时间窗口内的请求速率看作一个时间序列，ROC 就是相邻两个窗口速率的变化量。如果 ROC 突然增大，说明请求正在快速堆积，即使当前绝对请求数还不高，也应该提前限制。这种机制本质上是一种前馈控制，而固定阈值限流属于反馈控制。
一个典型的例子是电商秒杀接口。活动开始前一分钟，每秒请求数从 5 缓慢爬升到 40，此时 ROC 只有 35，属于正常预热。活动开始瞬间，大量用户同时点击，第一秒请求数直接跳到 600，ROC 高达 560。如果只设置每秒 200 的固定阈值，这一秒内会有 200 个请求进入核心服务，之后才开始拒绝；而引入 ROC 后，系统在请求数达到 80 左右时就可以判断增长速度异常，提前返回 429 或降级响应，把峰值削平。
二、基于 DelegatingHandler 的 ROC 计算组件
在 ASP.NET Web API 中，全局消息处理器（DelegatingHandler）是拦截请求的理想位置。它位于路由分发之前，可以对所有进入管道的请求做统一处理。我们需要在处理器中维护一个线程安全的时间戳队列，每次请求到达时记录当前 UTC 时间，并定期清理超过滑动窗口长度的旧数据。计算 ROC 时，将窗口分成前后两个半段，分别统计请求数量，然后换算成每秒速率，最后用后半段速率减去前半段速率得到变化率。
下面是一个可复用的滑动窗口 ROC 计算器类，内部使用 ConcurrentQueue<DateTime> 和锁来保证并发安全。窗口长度默认设置为 6 秒，前后半段各 3 秒，这样既能捕捉短时间内的流量突变，又不会因为单次毛刺产生过多误报。
public class SlidingWindowRocCalculator
{
private readonly ConcurrentQueue<DateTime> _timestamps = new ConcurrentQueue<DateTime>();
private readonly object _sync = new object();
private readonly int _windowSeconds;
private readonly int _maxQueueSize;
public SlidingWindowRocCalculator(int windowSeconds = 6, int maxQueueSize = 10000)
{
_windowSeconds = windowSeconds;
_maxQueueSize = maxQueueSize;
}
public void RecordRequest()
{
_timestamps.Enqueue(DateTime.UtcNow);
if (_timestamps.Count > _maxQueueSize)
{
lock (_sync)
{
while (_timestamps.Count > _maxQueueSize)
{
_timestamps.TryDequeue(out _);
}
}
}
}
public double GetRoc()
{
lock (_sync)
{
var now = DateTime.UtcNow;
var cutoff = now.AddSeconds(-_windowSeconds);
while (_timestamps.TryPeek(out var oldest) && oldest < cutoff)
{
_timestamps.TryDequeue(out _);
}
var snapshot = _timestamps.ToArray();
if (snapshot.Length == 0)
{
return 0;
}
var halfCutoff = now.AddSeconds(-_windowSeconds / 2.0);
int recentCount = snapshot.Count(t => t >= halfCutoff);
int previousCount = snapshot.Length - recentCount;
double halfWindow = _windowSeconds / 2.0;
double recentRate = recentCount / halfWindow;
double previousRate = previousCount / halfWindow;
return recentRate - previousRate;
}
}
}
这个实现中有几个细节需要注意。首先，清理过期数据必须在锁内进行，避免队列在遍历时被其他线程修改。其次，为了减少锁竞争，RecordRequest 方法在入队时并不加锁，只有当队列长度超过 _maxQueueSize 时才加锁清理，正常流量下性能开销极低。最后，GetRoc 使用快照数组做统计，防止锁定期间队列被修改导致计数偏差。窗口长度可按业务调整：交易类接口建议 4 到 6 秒，数据上报类接口可以放宽到 10 秒以上。
选型上，为什么不用简单的固定窗口计数？固定窗口在边界处容易出现两倍流量问题，例如第 1 秒最后 100 毫秒和第 2 秒前 100 毫秒各进入 200 个请求，两个窗口都没有超限，但实际 200 毫秒内涌入了 400 个请求。滑动窗口通过持续覆盖时间范围，消除了这种边界跳变，计算出的 ROC 也更平滑可信。
三、将 ROC 接入动态限流策略
有了 ROC 值之后，下一步是让它参与限流决策。最简单的策略是分级控制：当 ROC 超过预设的危险阈值时，立即将当前接口的允许速率下调到原来的三分之一；当 ROC 回落到安全区间并持续一段时间后，再逐步恢复。这样既能快速压制流量尖峰，又不会因为一次误报就长期降低服务能力。
下面是一个集成了 ROC 计算和动态阈值的 DelegatingHandler 示例。它根据请求路径生成缓存键，为每个路由维护独立的计算器。在实际生产环境中，可以使用 IMemoryCache 或分布式缓存来存储这些对象，避免单机内存无限增长。
public class RocRateLimitingHandler : DelegatingHandler
{
private readonly ConcurrentDictionary<string, SlidingWindowRocCalculator> _calculators =
new ConcurrentDictionary<string, SlidingWindowRocCalculator>();
private readonly ConcurrentDictionary<string, int> _currentLimits =
new ConcurrentDictionary<string, int>();
private readonly int _baseLimit = 200;
private readonly int _reducedLimit = 60;
private readonly double _dangerRocThreshold = 80.0;
private readonly double _safeRocThreshold = 20.0;
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
string path = request.RequestUri.AbsolutePath.ToLowerInvariant();
var calculator = _calculators.GetOrAdd(path, _ => new SlidingWindowRocCalculator());
calculator.RecordRequest();
double roc = calculator.GetRoc();
int currentLimit = _currentLimits.GetOrAdd(path, _baseLimit);
if (roc > _dangerRocThreshold)
{
currentLimit = _reducedLimit;
_currentLimits[path] = currentLimit;
}
else if (roc < _safeRocThreshold && currentLimit < _baseLimit)
{
currentLimit = Math.Min(_baseLimit, currentLimit + 20);
_currentLimits[path] = currentLimit;
}
// 这里还需要结合固定窗口计数来判断绝对数量是否超限
// 示例省略了计数部分，只展示 ROC 联动逻辑
if (IsOverLimit(path, currentLimit))
{
var response = request.CreateResponse(HttpStatusCode.TooManyRequests);
response.Content = new StringContent("请求过于频繁，请稍后重试");
return response;
}
return await base.SendAsync(request, cancellationToken);
}
private bool IsOverLimit(string path, int limit)
{
// 实际实现时应使用计数器或令牌桶
return false;
}
}
上面的代码简化了绝对计数部分，是为了突出 ROC 如何动态调整限流阈值。实际项目中，你需要在 IsOverLimit 中维护一个固定窗口或令牌桶计数器，并将 currentLimit 作为该计数器的上限。当 ROC 危险时，阈值被压低到 60，即使当前请求数还没达到 200，超过 60 的请求也会被拦截。当 ROC 恢复到安全值以下，阈值每次回调 20，直到恢复基础值 200。这种渐进恢复避免了阈值突然放开导致二次冲击。
关于状态码，建议返回 429 Too Many Requests，并在响应头中加入 Retry-After 字段，告知客户端何时可以重试。对于内部服务间调用，还可以选择返回 503 来触发熔断，但对外 API 使用 429 更符合 HTTP 语义。
四、分布式环境下的 ROC 限流扩展
单机版本适合单个实例部署的场景，但在微服务架构下，多个 API 实例往往共享同一个后端服务。如果每个实例独立计算 ROC 和限流，攻击者只要把流量分散到不同节点，就能绕过限制。因此分布式限流必须把统计数据集中存储。
Redis 是实现分布式计数和滑动窗口的首选。可以使用 Sorted Set 存储每个请求的时间戳，成员为唯一请求 ID，分数为 Unix 时间戳。每次请求到来时，先移除窗口外的成员，然后统计剩余成员数量并计算 ROC。为了避免多次网络往返和竞态条件，推荐使用 Lua 脚本在 Redis 服务端原子执行。
-- KEYS[1] 是请求路径对应的 Sorted Set 键
-- ARGV[1] 是当前时间戳（毫秒）
-- ARGV[2] 是窗口长度（毫秒）
-- ARGV[3] 是当前请求的唯一 ID
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, tonumber(ARGV[1]) - tonumber(ARGV[2]))
redis.call('ZADD', KEYS[1], ARGV[1], ARGV[3])
local total = redis.call('ZCARD', KEYS[1])
local half = tonumber(ARGV[1]) - tonumber(ARGV[2]) / 2
local recent = redis.call('ZCOUNT', KEYS[1], half, tonumber(ARGV[1]))
local previous = total - recent
local half_window = tonumber(ARGV[2]) / 2000
local roc = recent / half_window - previous / half_window
redis.call('EXPIRE', KEYS[1], tonumber(ARGV[2]) * 2)
return {total, roc}
这个 Lua 脚本返回窗口内总请求数和 ROC 值，应用层可以拿到结果后再决定是否拒绝当前请求。需要注意的是，分布式环境下所有实例的时钟可能存在偏差，因此时间戳应尽量使用 Redis 服务器的 TIME 命令获取，或者在所有应用实例上启用 NTP 时间同步，把偏差控制在几十毫秒以内。如果时钟不同步，滑动窗口计算会出现窗口覆盖范围不一致，导致 ROC 抖动。
此外，Redis 的 Sorted Set 在请求量极大时会有内存压力，可以定期清理或者改用 Redis Streams 结合消费者组做更高效的统计。监控方面，建议把每个路径的 ROC 值和实际限流次数写入性能计数器或日志系统，当 ROC 超过危险阈值时触发告警，这样运维团队可以在用户投诉之前发现异常流量。
ROC 变化率限流并不是要取代传统限流算法，而是作为前馈信号与之配合。固定窗口或令牌桶负责守住绝对底线，ROC 负责在流量爬升阶段提前行动。两者组合后，ASP.NET Web API 在面对突发流量时能够更快做出反应，同时保留足够的灵活性，避免误伤正常用户。对于读完本文后准备落地的开发者，建议先在预发环境模拟几种流量模型，观察不同窗口长度和阈值设置下的限流表现，再逐步推广到生产接口。
ASP.NET Web APIROC变化率动态限流修改时间：2026-09-25 04:50:27