漏桶算法的核心逻辑是什么
漏桶算法本质是用固定速率“漏水”的容器来约束请求流入。它不关心突发流量有多大，只保证流出速率恒定。在 C# 中实现时，关键不是模拟水滴物理过程，而是维护两个状态：
currentLevel（当前桶中水量，即待处理请求数）和
lastLeakTime（上次漏水时间），再按时间推算已自然漏掉多少请求。
用 ConcurrentDictionary
+ DateTime.UtcNow
实现线程安全的单机限流
不需要引入 Redis 或外部依赖，纯内存实现适用于单服务实例场景。重点在于避免锁竞争，同时保证时间计算不被系统时钟回拨干扰。
ConcurrentDictionary<string bucketstate></string>按 API 路径或用户 ID 分桶，key 建议包含租户/用户标识以支持细粒度控制 每次请求调用
TryAcquire()方法：先读取当前桶状态，再按时间差计算应漏掉的量，更新
currentLevel，最后判断是否 ≤ 容量 必须用
DateTime.UtcNow，不能用
DateTime.Now，否则跨时区或本地时钟不准会导致误判 更新状态时使用
GetOrAdd+
CompareExchange模式，避免竞态下覆盖他人写入
public class LeakyBucketRateLimiter
{
private readonly ConcurrentDictionary<string, BucketState> _buckets = new();
private readonly int _capacity;
private readonly double _leakRatePerSecond; // 每秒漏出请求数，如 10 表示 QPS=10
<pre class='brush:php;toolbar:false;'>public LeakyBucketRateLimiter(int capacity, double leakRatePerSecond)
{
_capacity = capacity;
_leakRatePerSecond = leakRatePerSecond;
}
public bool TryAcquire(string key)
{
var now = DateTime.UtcNow;
var bucket = _buckets.GetOrAdd(key, _ => new BucketState());
while (true)
{
var snapshot = bucket.Value;
var elapsedSeconds = (now - snapshot.LastLeakTime).TotalSeconds;
var leaked = elapsedSeconds * _leakRatePerSecond;
var newLevel = Math.Max(0, snapshot.CurrentLevel - leaked);
var updated = new BucketState
{
CurrentLevel = newLevel + 1,
LastLeakTime = now
};
if (newLevel + 1 <= _capacity)
{
if (bucket.CompareExchange(updated, snapshot) == snapshot)
return true;
}
else
{
// 超过容量，不增加 currentLevel，只更新时间以便下次计算漏水量
var idleUpdate = new BucketState
{
CurrentLevel = newLevel,
LastLeakTime = now
};
bucket.CompareExchange(idleUpdate, snapshot);
return false;
}
}
}
private class BucketState
{
public double CurrentLevel { get; set; }
public DateTime LastLeakTime { get; set; } = DateTime.UtcNow;
}}
为什么不用 Timer
或后台线程主动漏水
主动定时“漏水”看似直观，但实际会带来严重问题：
每个桶配一个Timer→ 内存与线程开销爆炸，尤其 key 多时（如每用户一桶） Timer 触发非实时，可能延迟几十毫秒，导致限流精度下降 应用重启时 Timer 状态丢失，而按需计算的方式天然无状态、可热启 漏桶本就是被动模型——只在请求来时才结算“到目前为止漏了多少”，这才是符合语义的实现
部署到 ASP.NET Core 的中间件里要注意什么
直接注入
LeakyBucketRateLimiter实例到 DI 容器没问题，但必须注意生命周期和 key 构造： 注册为
Singleton，桶状态要跨请求共享 key 不要只用
httpContext.Request.Path，建议组合
ip + path或
userId + path，否则所有用户共用一个桶就失去意义 若用 JWT，可在中间件里解析
HttpContext.User.Identity.Name或自定义 claim 获取用户标识 返回 429 时，建议加
Retry-After响应头，值可估算：`(currentLevel / leakRatePerSecond)` 秒后才可能通过
漏桶真正难的不是代码几行，而是 key 的语义设计和漏率单位的对齐——比如你设了每秒漏 5 个，但业务上其实是“每 200ms 放行 1 个”，这两者在浮点运算下会有累积误差，高并发下可能偏移数百毫秒。上线前务必用
Stopwatch做真实吞吐压测，别只信理论计算。
