C++中的速率限制与节流：如何保护API免受过载

当您的API开始不堪重负：速率限制简介

想象一下这种情况：您用C++编写了一个完美的服务器。它快速、高效，充分利用了所有CPU核心。您将其部署到生产环境，然后……五分钟后它崩溃了。发生了什么？原来，某个恶意脚本决定“测试”您的API，每秒发送数千个请求。

熟悉吗？如果不熟悉——那您很幸运。但迟早，每个开发者都会面临控制负载的需求。正是在这里，速率限制和节流登场了——这两种强大的机制能够拯救服务器免受过载，并确保资源的均匀分配。

在本文中，我们将探讨如何在C++中实现这些机制。您不仅会学到理论，还会获得可以直接在项目中使用的可运行代码。我们开始吧！

速率限制 vs 节流：有什么区别？

在深入代码之前，让我们明确区分这两个概念。很多人会混淆它们，但区别是存在的，而且至关重要。

速率限制

这就像“栏杆”。您规定：“每秒最多10个请求。超出部分——要么禁止（要么排队）”。速率限制保护您的API免受请求洪流、DDoS攻击和突发流量高峰的影响。

节流

这就像“音量调节器”。您不会完全阻止请求，而是减慢它们的处理速度。例如，如果客户端每秒发送100个请求，您会处理它们，但每个请求之间会有10毫秒的延迟。节流是一种更“礼貌”的负载管理方式，它不会丢弃数据，只是平滑峰值。

在实际项目中，这些技术经常结合使用：先用节流平滑流量，当超过临界阈值时，再用速率限制并返回429错误（请求过多）。

C++中的速率限制算法

有几种经典算法。我们将介绍两种最流行且高效的：令牌桶和滑动窗口。两者都很容易在C++中实现，并能带来出色的效果。

1. 令牌桶

想象一个桶，每秒有N个令牌滴入其中。每个请求消耗一个令牌。如果桶空了——请求被拒绝。简单而巧妙。

以下是使用现代C++和std::chrono的实现：

#include <chrono>#include <mutex>#include <atomic>

class TokenBucket {public:    TokenBucket(size_t max_tokens, double refill_rate)        : max_tokens_(max_tokens)        , refill_rate_(refill_rate)        , current_tokens_(max_tokens)        , last_refill_(std::chrono::steady_clock::now()) {}

    bool try_consume() {        std::lock_guard<std::mutex> lock(mutex_);                // 计算自上次以来累积的令牌数        auto now = std::chrono::steady_clock::now();        auto elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(now - last_refill_);                // 补充令牌桶        double tokens_to_add = elapsed.count() * refill_rate_ / 1000.0;        current_tokens_ = std::min(max_tokens_, current_tokens_ + tokens_to_add);        last_refill_ = now;                // 尝试消耗一个令牌        if (current_tokens_ > 0) {            --current_tokens_;            return true;        }        return false;    }

private:    std::mutex mutex_;    size_t max_tokens_;           // 桶的最大容量    double refill_rate_;          // 每秒令牌数    double current_tokens_;       // 当前令牌数量    std::chrono::steady_clock::time_point last_refill_;};

使用方法：

TokenBucket limiter(10, 1.0); // 10个令牌，每秒补充1个令牌

// 在请求处理程序中：if (limiter.tr