亿级流量系统架构设计与实战（七）

WispX888

于 2025-05-12 00:00:00 发布

阅读量815

点赞数 9

文章标签：系统架构 java 架构设计微服务治理手段阅读笔记亿级流量架构

本文链接：https://blog.csdn.net/WispX888/article/details/147732664

版权

限流

常见的限流方式

频控：控制用户在 N 秒内只可执行 M 次操作。
- 比如限制用户在 30s 内只能下载 1 次文件、在 1h 内最多只能发布 5 条动态。
单机限流 + 固定阈值： 某服务的每台服务器在 1s 内最多可处理 M 个请求， M 值是预先设置好的。
全局限流 + 固定阈值： 某服务在 1s 内总共可处理 M 个请求，与前者的主要区别在于限流范围是某服务的全部服务实例。
单机自适应限流 ：某服务的每台服务器根据自身服务状况，使用各种自动化算法动态判断是否限制请求，不再预先设置限流阈值.

频控

Redis 实现频控。

N 秒内执行 1 次

核心 Reids 命令：SET your_key_{xxID} 0 EX 30 NX

服务中执行该命令成功，则可以访问；执行失败，则不可访问，直接返回。

N 秒内最多执行 M 次

核心思想：向 Redis 中设置一个 Key，过期时间为 N 秒，Key 的 value 最大为 M。

这里涉及到 INCR（自增）和 EXPIRE ( 设置过期时间) 两个命令，需要使用 LUA 脚本保证这两个命令的原子性。

以用户在 1h 内最多只能发布 5 条动态为例，其 Lua 脚本实现如下：

local count = redis.call('incr', 'publish_{userID}') // 没有这个key，就加到 1
if count == 1 then // 判断是否为首次设置，如果是，需要设置过期时间
  redis.call('expire', 'publish_{userID}', 3600) // 设置过期时间为 lh
end
return count // 返回最新计数

服务调用该脚本，返回的值 < 5，那么可以访问服务。

单机限流 1 ：时间窗口

核心思想：维护了一个初始值不为 0 的数组，每次请求时都需要从数组中减一。

固定时间窗口

比如限制在 1s 内请求量不超过100 个，可以将时间线切分为以 1s 为单位的时间窗口，每个时间窗口都维护这 1s 内允许通过的计数 100。

当请求到来时，先向当前所处的时间窗口申请 1 个计数，如果该时间窗口内的计数大于 0，则计数减 1 并允许请求通过；否则，请求被限流器丢弃。

缺点

窗口边界流量暴增：无法防止时间窗口边界附近的流量暴增，可能会有 2 倍限流阈值的请求通过限流器。
- 11:30:06 时前 500 ms 没有请求，后 500 ms 请求了 100 次，11:30:07 时前 500 ms 请求了 100 次。也就是在 1 s内请求了 200 次。远超所设置的阈值。