C#第三方API多维度限流实现方案是否无Bug？求优化建议

我正在使用第三方API，该API设有每分钟、每15分钟及每小时的调用限制，且通常每小时限制小于每分钟限制×60（1小时=60分钟）。
有时我需要执行批量更新，因此需要多次调用该接口，但又不想超出限制触发错误。

我在C# Worker Service中实现了以下代码片段：

int ratePerHour = HardCodedRatePerHour;
int counter = 0;
int rateLimitPerMinute = ratePerHour / 60
Stopwatch stopwatch = Stopwatch.StartNew();
foreach (var item in itemsToBeUpdated) 
{
    await UpdateItemUsingThirdPartyWithRateLimit(item, stoppingToken)
    counter++;
    counter = await WaitInCaseOfGoingOverRateLimit(rateLimitPerMinute, stopwatch, counter, stoppingToken);
}

对应的WaitInCaseOfGoingOverRateLimit方法如下：

private static async Task<int> WaitInCaseOfGoingOverRateLimit(int ratePerMinute, Stopwatch stopwatch, int countOfItemsProcessedSinceLastStopWatchRestart, CancellationToken stoppingToken)
{
    int duration = (int)stopwatch.Elapsed.TotalSeconds;
    if (duration < 60 && countOfItemsProcessedSinceLastStopWatchRestart >= ratePerMinute)
    {
        Console.WriteLine($"Sleeping for {60 - duration} seconds. In the last minute, {countOfItemsProcessedSinceLastStopWatchRestart} number of items have been updated");
        await Task.Delay((60 - duration) * 1000, stoppingToken);
        countOfItemsProcessedSinceLastStopWatchRestart = 0;
        stopwatch.Restart();
    }
    else if (duration > 60)
    {
        Console.WriteLine($"No need to sleep on this batch. In the last minute, {countOfItemsProcessedSinceLastStopWatchRestart} number of items have been updated");
        countOfItemsProcessedSinceLastStopWatchRestart = 0;
        stopwatch.Restart();
    }

    return countOfItemsProcessedSinceLastStopWatchRestart;
}

该方法的逻辑说明：

• 当计时超过60秒或触发限流时，重启秒表
• 重启秒表时始终将计数器重置为0
• 若超出限流，将延迟执行至下一分钟开始
• 若未超出限流且秒表自上次重启后未过60秒，则保持计数器不变
• 每次循环迭代计数器加1

请问这是否为正确的限流处理方式？有无优化建议？

现有代码的问题 #

当前实现仅能处理单分钟级别的限流，完全忽略了API设置的15分钟和每小时限制——而题目明确提到每小时限制小于每分钟限制×60，按当前逻辑运行，大概率会在1小时内触发小时级限流。

除此之外还有几个细节漏洞：

1. 整数除法浪费配额：rateLimitPerMinute = ratePerHour / 60会丢失余数，比如小时限制350次时，每分钟只能算5次（350/60=5），但实际每小时可调用350次，均匀分配的话每分钟约5.83次，当前逻辑会浪费近14%的配额。
2. 等待逻辑过于粗暴：如果在第59秒触发分钟限流，只需等待1秒，但当前逻辑会直接等至下一分钟开始，完全没必要。
3. 边界条件未处理：当秒表刚好走满60秒时，代码不会重置计数器和秒表，会导致计数器持续累加，后续误触发限流判断。
4. 无全局控制能力：如果Worker Service是多实例部署，或者这段代码在多线程环境下运行，局部变量的计数器和秒表无法全局控频，会导致总调用量直接超出限制。

优化建议 #

1. 实现多时间窗口限流逻辑 #

必须同时跟踪分钟、15分钟、小时三个时间窗口的调用次数，确保每个窗口内的调用量都不超限。推荐用固定窗口实现（逻辑简单，性能开销低）：

public class RateLimiter
{
    private readonly int _perMinute;
    private readonly int _per15Minutes;
    private readonly int _perHour;
    
    private int _minuteCount;
    private DateTime _minuteWindowStart;
    private int _quarterHourCount;
    private DateTime _quarterHourWindowStart;
    private int _hourCount;
    private DateTime _hourWindowStart;
    private readonly object _lock = new object();

    public RateLimiter(int perMinute, int per15Minutes, int perHour)
    {
        _perMinute = perMinute;
        _per15Minutes = per15Minutes;
        _perHour = perHour;
        var now = DateTime.UtcNow;
        _minuteWindowStart = now;
        _quarterHourWindowStart = now;
        _hourWindowStart = now;
    }

    public async Task WaitForQuotaAsync(CancellationToken cancellationToken)
    {
        while (true)
        {
            lock (_lock)
            {
                var now = DateTime.UtcNow;
                // 重置过期的时间窗口
                if (now - _minuteWindowStart >= TimeSpan.FromMinutes(1))
                {
                    _minuteCount = 0;
                    _minuteWindowStart = now;
                }
                if (now - _quarterHourWindowStart >= TimeSpan.FromMinutes(15))
                {
                    _quarterHourCount = 0;
                    _quarterHourWindowStart = now;
                }
                if (now - _hourWindowStart >= TimeSpan.FromHours(1))
                {
                    _hourCount = 0;
                    _hourWindowStart = now;
                }

                // 所有窗口都有剩余配额时，计数+1并返回
                if (_minuteCount < _perMinute && _quarterHourCount < _per15Minutes && _hourCount < _perHour)
                {
                    _minuteCount++;
                    _quarterHourCount++;
                    _hourCount++;
                    return;
                }
            }

            // 计算需要等待的最短时间（取所有窗口中最早重置的时间）
            var waitTime = GetShortestResetTime();
            await Task.Delay(waitTime, cancellationToken);
        }
    }

    private TimeSpan GetShortestResetTime()
    {
        var now = DateTime.UtcNow;
        var minuteReset = _minuteWindowStart.AddMinutes(1) - now;
        var quarterReset = _quarterHourWindowStart.AddMinutes(15) - now;
        var hourReset = _hourWindowStart.AddHours(1) - now;
        
        return new[] { minuteReset, quarterReset, hourReset }
            .Where(t => t > TimeSpan.Zero)
            .Min();
    }
}

使用方式：

// 初始化限流器，传入三个窗口的限制值
var rateLimiter = new RateLimiter(PerMinuteLimit, Per15MinutesLimit, PerHourLimit);
foreach (var item in itemsToBeUpdated)
{
    // 先等配额，再调用API
    await rateLimiter.WaitForQuotaAsync(stoppingToken);
    await UpdateItemUsingThirdPartyWithRateLimit(item, stoppingToken);
}

2. 其他细节优化 #

• 用DateTime.UtcNow替代秒表：避免本地时间偏移问题，更方便计算窗口剩余时间。
• 优化配额分配：针对小时限制小于分钟限制×60的情况，可以把剩余配额分散到各个分钟窗口，比如小时限制350次时，前50分钟每分钟允许6次，后10分钟每分钟5次，最大化利用配额。
• 增加容错逻辑：捕获API返回的429限流错误，此时主动延长等待时间，并实现指数退避策略（比如第一次等2秒，第二次等4秒，以此类推）。
• 分布式场景适配：如果是多实例部署，改用Redis等分布式缓存维护全局计数器，避免跨实例的控频失效。

内容的提问来源于stack exchange，提问作者Sina Sarshar Pour