云加社区

5大常见高并发限流算法选型浅析

Image

Image

👉目录

1 固定窗口算法(Fixed Window Algorithm)

2 滑动窗口算法(Sliding Window Algorithm)

3 滑动日志算法(Sliding Log Algorithm)

4 漏桶算法(Leaky Bucket Algorithm)

5 令牌桶算法(Token Bucket Algorithm)

6 总结

在现代高并发系统中,随着用户访问量的激增和业务需求的不断扩展,限流作为一种至关重要的保护机制,被广泛应用于防止系统过载,确保系统的稳定性和可用性。

本文将深入剖析几种常见的限流算法,探讨它们的原理、优缺点并给出代码实例,帮助读者更好地理解和应用这些算法,从而在实际项目中构建更加高效、稳定的系统。

关注腾讯云开发者,一手技术干货提前解锁👇

01

固定窗口算法(Fixed Window Algorithm)
Image
固定窗口算法将时间划分为固定大小的窗口(如1min),在每个窗口内允许一定数量的请求。每当请求到达时,系统会检查当前窗口内的请求数量,如果未超过限制,则允许请求;否则,拒绝请求。
class FixedWindowRateLimiter {public:    FixedWindowRateLimiter(int max_requests_per_win, std::chrono::seconds window_size)        : max_requests_per_win_(max_requests_per_win), window_size_(window_size), request_count_(0) {        window_start_time_ = std::chrono::steady_clock::now();    }
bool TryAcquire(int request_size) { std::lock_guard<std::mutex> lock(mtx_); auto now = std::chrono::steady_clock::now();
// 如果当前时间在窗口内 if (now - window_start_time_ < window_size_) { // 检查请求数量是否超过限制 if (request_count_ + request_size <= max_requests_per_win_) { request_count_ += request_size; // 增加请求计数 return true; // 允许请求 } else { return false; // 超过最大请求数 } } else { // 重置窗口 window_start_time_ = now; request_count_ = request_size; // 重置请求计数为当前请求数量 return true; // 允许请求 } }
private: int max_requests_per_win_; // 最大请求数 std::chrono::seconds window_size_; // 窗口大小 int request_count_; // 当前请求计数 std::chrono::steady_clock::time_point window_start_time_; // 窗口开始时间 std::mutex mtx_; // 互斥锁};

优点

  • 实现简单,非常容易理解。

  • 适用于请求速率相对稳定的场景。

缺点

  • 在短时间流量突发时,将会有大量失败,无法平滑流量。

  • 有窗口边际效应:在窗口切换时,可能会出现短时间内请求激增的情况,导致系统过载。

02

滑动窗口算法(Sliding Window Algorithm)
Image
滑动窗口算法是对固定窗口算法的改进,它将时间窗口划分为多个小桶,并为每个小桶维护一个独立的请求计数器。当请求到达时,算法会根据请求的时间戳将其放入相应的小桶中,并检查整个滑动窗口内的请求总数是否超过限制。随着时间的推移,滑动窗口会不断向右滑动,丢弃最旧的小桶并添加新的小桶。
class SlidingWindowRateLimiter {public:    SlidingWindowRateLimiter(int max_requests_per_win, std::chrono::seconds bucket_size, int num_buckets)        : max_requests_per_win_(max_requests_per_win), bucket_size_(bucket_size), num_buckets_(num_buckets) {        request_counts_.resize(num_buckets, 0);        last_bucket_time_ = std::chrono::steady_clock::now();    }
bool TryAcquire(int request_size) { std::lock_guard<std::mutex> lock(mtx_); auto now = std::chrono::steady_clock::now(); UpdateBuckets_(now);
int total_requests = 0; for (int count : request_counts_) { total_requests += count; }
if (total_requests + request_size <= max_requests_per_win_) { request_counts_[current_bucket_index_] += request_size; // 增加当前桶的请求计数 return true; // 允许请求 } else { return false; // 超过最大请求数 } }
private: void UpdateBuckets_(std::chrono::steady_clock::time_point now) { auto elapsed = std::chrono::duration_cast<std::chrono::seconds>(now - last_bucket_time_); int buckets_to_update = static_cast<int>(elapsed / bucket_size_);
if (buckets_to_update > 0) { for (int i = 0; i < std::min(num_buckets_, buckets_to_update); ++i) { auto next_bucket_index = (current_bucket_index_ + 1) % num_buckets_; request_counts_[next_bucket_index] = 0; // 移除最旧的桶 current_bucket_index_ = next_bucket_index; // 移动到下一个桶 } last_bucket_time_ += buckets_to_update * bucket_size_; // 更新最后桶的时间 } }
int max_requests_per_win_; // 最大请求数 std::chrono::seconds bucket_size_; // 每个小桶的大小 int num_buckets_; // 小桶的数量 std::vector<int> request_counts_; // 每个小桶的请求计数 std::mutex mtx_; // 互斥锁 std::chrono::steady_clock::time_point last_bucket_time_; // 上一个桶的时间 int current_bucket_index_ = 0; // 当前桶的索引};

优点

  • 相比固定窗口算法可以更细粒度地控制流量。

  • 减缓了固定窗口算法中的窗口边际效应。

缺点

  • 在短时间流量突发时,将会有大量失败,无法平滑流量。

03

滑动日志算法(Sliding Log Algorithm)
Image
滑动日志算法通过记录每个请求的时间戳来控制请求速率。当一个请求到达时,系统会检查最近一段时间内的请求记录,计算请求速率是否超过限制。如果超过,则拒绝请求;否则,处理请求并记录当前请求的时间戳。
class SlidingLogRateLimiter {public:    SlidingLogRateLimiter(int max_requests_per_win, std::chrono::seconds window_size)        : max_requests_per_win_(max_requests_per_win), window_size_(window_size) {}
bool TryAcquire(int request_size) { std::lock_guard<std::mutex> lock(mtx_); auto now = std::chrono::steady_clock::now(); CleanUp_(now);
int total_requests = 0; for (const auto& timestamp : request_log_) { total_requests += timestamp.second; }
if (total_requests + request_size <= max_requests_per_win_) { request_log_.emplace_back(now, request_size); // 记录当前请求 return true; // 允许请求 } else { return false; // 超过最大请求数 } }
private: void CleanUp_(std::chrono::steady_clock::time_point now) { auto expiration_time = now - window_size_; while (!request_log_.empty() && request_log_.front().first < expiration_time) { request_log_.pop_front(); // 移除过期的请求记录 } }
int max_requests_per_win_; // 最大请求数 std::chrono::seconds window_size_; // 窗口大小 std::deque<std::pair<std::chrono::steady_clock::time_point, int>> request_log_; // 请求日志 std::mutex mtx_; // 互斥锁};

优点

  • 可以非常精确地控制请求速率。

缺点

  • 在短时间流量突发时,将会有大量失败,无法平滑流量。

  • 由于每一次成功请求都要被记录,所以会有较大额外的内存开销。

04

漏桶算法(Leaky Bucket Algorithm)
Image
漏桶算法将请求看作水滴,将请求处理过程看作水从漏桶底部中流出。系统以恒定速率处理请求(即漏桶的漏水速率),当一个请求到达时,如果漏桶未满,则请求被放入漏桶中等待处理;如果漏桶已满,则请求被拒绝。
class Task {public:    virtual int GetLoad() = 0;    virtual void Run() = 0;}
class LeakyBucketRateLimiter {public: LeakyBucketRateLimiter(int capacity, int leak_rate) : capacity_(capacity), leak_rate_(leak_rate), current_water_(0) { last_leak_time_ = std::chrono::steady_clock::now(); }
bool TryRun(const TaskPtr& task) { std::lock_guard<std::mutex> lock(mtx_); Leak();
if (current_water_ + task.GetLoad() <= capacity_) { current_water_ += task.GetLoad(); // 将请求放入漏桶 heap_timer_.Schedule(task, current_water_ / leak_rate); // 定时器在该任务的水漏完后将会执行task的Run方法 return true; // 允许请求 } else { return false; // 漏桶已满,请求被拒绝 } }
private: void Leak() { auto now = std::chrono::steady_clock::now(); auto elapsed = std::chrono::duration_cast<std::chrono::seconds>(now - last_leak_time_); int leaked_water = static_cast<int>(elapsed.count()) * leak_rate_;
if (leaked_water > 0) { current_water_ = std::max(0, current_water_ - leaked_water); // 减少水量 last_leak_time_ = now; // 更新最后漏水时间 } }
int capacity_; // 漏桶的容量 int leak_rate_; // 漏水速率(每秒漏掉的水量) int current_water_; // 当前水量 HeapTimer heap_timer_; // 一个任务执行的定时器 std::mutex mtx_; // 互斥锁 std::chrono::steady_clock::time_point last_leak_time_; // 上次漏水的时间};

优点

  • 能提供非常平稳的流量。

  • 削峰填谷,有一定的应对流量突发能力(桶的大小)。

缺点

  • 控制比较刻板,弹性能力较弱。

  • 在并发时候会产生额外的延迟等待开销(比如限制流量为1qps,两个请求同时到达,必然有其中一个请求需要等1s后才能服务)。

05

令牌桶算法(Token Bucket Algorithm)
Image
令牌桶算法使用一个桶来存储令牌,以固定速率向桶中添加令牌。每当请求到达时,会先检查桶中是否有令牌,如果有,则允许请求并消耗相应令牌;如果没有,则拒绝请求。
class TokenBucketRateLimiter {public:    TokenBucketRateLimiter(int capacity, int refill_rate)        : capacity_(capacity), refill_rate_(refill_rate), current_tokens_(0) {        last_refill_time_ = std::chrono::steady_clock::now();    }
bool TryAcquire(int request_size) { std::lock_guard<std::mutex> lock(mtx_); Refill_();
if (current_tokens_ >= request_size) { current_tokens_ -= request_size; // 消耗令牌 return true; // 允许请求 } else { return false; // 令牌不足,请求被拒绝 } }
private: void Refill_() { auto now = std::chrono::steady_clock::now(); auto elapsed = std::chrono::duration_cast<std::chrono::seconds>(now - last_refill_time_); current_tokens_ = std::min(capacity_, current_tokens_ + static_cast<int>(elapsed.count()) * refill_rate_); // 更新令牌数量 last_refill_time_ = now; // 更新最后补充时间 }
int capacity_; // 令牌桶的容量 int refill_rate_; // 令牌补充速率(每秒补充的令牌数量) int current_tokens_; // 当前令牌数量 std::mutex mtx_; // 互斥锁 std::chrono::steady_clock::time_point last_refill_time_; // 上次补充令牌的时间};

优点

  • 能够处理突发流量,避免系统瞬间过载。

  • 灵活性高,可以通过调整令牌生成速率和桶容量来控制流量。

缺点

  • 实现相对复杂。

06

总结
每种限流算法都有其适用的场景和优缺点。在选择限流算法时,需要根据具体的业务需求和系统特性进行权衡。通过合理选择和组合这些算法,可以有效地保护系统免受过载的影响。
-End-
原创作者|林思捷

Image

限流算法常用在哪些业务场景?欢迎评论留言。我们将选取1则优质的评论,送出腾讯云定制文件袋套装1个(见下图)。12月19日中午12点开奖。

Image

📢📢欢迎加入腾讯云开发者社群,享前沿资讯、大咖干货,找兴趣搭子,交同城好友,更有鹅厂招聘机会、限量周边好礼等你来~

Image

(长按图片立即扫码)

Image
Image

Image

Image

Image