C++实现基于时间戳的限流算法 _ 令牌桶与漏桶原理实现【源码】

C++实现基于时间戳的限流算法：令牌桶与漏桶原理实现【源码】

开门见山，先说结论：在C++服务端开发中，利用std::chrono配合原子变量，完全可以构建出线程安全且开销极低的令牌桶限流器。至于漏桶算法，在纯内存的服务端限流场景里，其实很少有必要去实现——它的核心是“恒定速率输出”，而服务端限流真正要防范的，往往是突发流量冲击。相比之下，令牌桶“允许突发+平滑限流”的特性，显然更贴合实际需求。

令牌桶：用 std::atomic 和 std::chrono::steady_clock 管理剩余令牌

实现高性能令牌桶，关键在于思路的转变：核心不是每秒去重置令牌数量，而是根据当前时刻，动态计算出“此刻应该有多少令牌”。这样一来，就彻底摆脱了对定时器或后台线程的依赖。具体怎么操作？有几个关键点需要把握：

• capacity（桶容量）和rate_per_sec（填充速率）是基础配置，例如可以设为每秒填充100个令牌，桶最大容量为200个。
• 存储的核心不是令牌数量本身，而是std::atomic类型的上一次填充时间戳（建议使用纳秒精度）。这个设计能大幅减少竞态条件。
• 每次请求到来时，先计算出从上次填充到现在，理论上应增加的令牌数。公式是：(当前时间 - 上次填充时间) * 填充速率 / 10^9。然后，将这个数值与当前剩余令牌数取最小值，得到实际可用令牌。
• 最后判断是否放行：如果可用令牌数 >= 本次请求消耗数，则通过原子操作更新剩余令牌值，并返回true。

来看一段示例代码的关键片段：

bool tryConsume(int tokens = 1) {
    auto now = std::chrono::steady_clock::now().time_since_epoch().count();
    auto& last = last_fill_time_;
    auto prev = last.load(std::memory_order_relaxed);
    long long a vail = 0;
    do {
        auto elapsed_ns = now - prev;
        double added = elapsed_ns * rate_per_sec_ / 1e9;
        a vail = std::min(static_cast(added), capacity_);
        if (a vail < tokens) return false;
    } while (!last.compare_exchange_weak(prev, now, std::memory_order_relaxed));
    // 此处需用 CAS 更新剩余令牌数（略去具体实现，推荐用带版本号的双原子变量或 mutex）
    return true;
}

想深入掌握？可以立即学习“C++免费学习笔记（深入）”。

漏桶不适合做接入层限流：它不解决“突发允许通过”的问题

为什么说漏桶在接入层限流中常常水土不服？根源在于它的设计哲学：强制以恒定速率输出请求。这意味着，即便桶是空的，新来的请求也只能排队等待。在HTTP接入层，这会直接放大请求延迟。更关键的是，它无法应对那些合理的、短时间的流量突增，比如秒杀活动的预热阶段。

实践中，漏桶常被误用，有几个典型的坑：

• 用std::queue加一个定时器来模拟“漏水”，结果往往因为定时器精度差、线程调度抖动，导致实际漏速完全不可控。
• 把漏桶简单当成“请求队列长度限制器”，但这本质上只是削峰填谷，并非严格意义上的限流。真正的限流，在超出能力时必须果断拒绝，而非无限制排队。
• 试图混合使用令牌桶和漏桶，比如“令牌桶准入，漏桶排队”，这种设计不仅增加了系统复杂度，还可能带来额外的延迟，收益却微乎其微。

话说回来，漏桶就一无是处吗？当然不是。它真正的用武之地，在于那些对速率稳定性有硬性要求的场景，比如底层IO调度或硬件限速。在这些地方使用，也必须配合高精度时钟（例如CLOCK_MONOTONIC_RAW）甚至内核旁路技术，才有实际意义。

线程安全与性能陷阱：别用 std::mutex 锁整个桶

高并发场景下，如果用std::mutex把整个桶锁住，那性能基本就归零了，所有请求都会串行化。正确的做法是：

• 所有读操作，比如时间计算、令牌估算，全部走无锁路径。只在最后真正扣减令牌的那一步，做最小粒度的CAS（比较并交换）操作。
• 坚决避免使用std::time(nullptr)或gettimeofday()这类可能发生时间回跳且精度不高的函数。必须使用std::chrono::steady_clock。
• 桶容量capacity不要设置得过大（比如10万）。过大的数值会导致浮点误差累积，建议控制在1000以内，并尽量使用整数运算来替代浮点运算。
• 如果需要做分布式限流，那么本地的令牌桶只能作为最后一道防线。核心的限流逻辑必须下沉，采用Redis+Lua脚本（例如redis-cell模块）或者专用的限流服务来实现。

还有一个极易被忽略的设计要点：令牌桶对突发流量的容忍能力，其实取决于capacity和rate_per_sec的比值。把配置设为100/100和1000/100，看上去平均速率都是100 QPS，但后者允许在某一秒内突发处理1000个请求——这个细微的设计权衡，文档里往往不提，可一旦线上流量出现波动，全靠它来兜底。

结论：C++中用std::chrono和原子变量可实现线程安全、低开销的令牌桶限流，而漏桶在纯内存服务端限流中基本不适用，因其无法应对突发流量，仅适合底层IO等对恒定速率有硬性要求的场景。