ThinkPHP Redis限流令牌桶算法代码实现示例-ThinkPHP-PHP中文网

ThinkPHP 本身不内置令牌桶，必须用 Redis::eval 执行 Lua 脚本原子实现，否则高并发下必超发；核心是 tokens 与 last_fill_time 双状态更新、补令牌计算及判断必须在单次 Lua 调用中完成，禁止 GET+DECR 拆分操作。

thinkphp redis限流令牌桶算法代码实现示例

ThinkPHP 中用 Redis 实现令牌桶限流的关键逻辑

直接说结论：ThinkPHP 本身不内置令牌桶，必须自己用 Redis::eval 或原子操作组合实现，否则在并发下会漏桶或超发。核心在于「获取令牌」这一步不能拆成 GET + DECR 两步，得用 Lua 脚本保证原子性。

为什么不能只用 `redis->decr()` 判断剩余数

常见错误是先 get 当前令牌数，再 decr，中间可能被其他请求插队，导致超发。尤其在高并发时，decr 返回负数也不代表“没令牌了”，因为没同步更新时间戳和重置逻辑。

令牌桶需同时维护两个状态：tokens（当前令牌数）和 last_fill_time（上次填充时间）
每次请求要先算出应补充多少令牌：min(capacity, tokens + (now - last_fill_time) * rate)
这个计算 + 更新必须在一个 Lua 脚本里完成，否则 race condition 不可避免

一个可用的 ThinkPHP + Redis 令牌桶 Lua 脚本封装

把 Lua 脚本写进 app/common/behavior/RateLimit.php 或单独工具类里，调用时传入 key、容量、速率（token/s）、过期时间：

// Lua 脚本内容（注意：换行和空格会影响 SHA1，建议存为字符串常量）
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local expire = tonumber(ARGV[3])
local now = tonumber(ARGV[4])
<p>local tokens_key = key .. ':tokens'
local time_key = key .. ':time'</p><p>local tokens = tonumber(redis.call('GET', tokens_key) or capacity)
local last_fill = tonumber(redis.call('GET', time_key) or now)</p><p>local delta = math.max(0, now - last_fill)
local fill = math.floor(delta * rate)
local new_tokens = math.min(capacity, tokens + fill)</p><p>local allowed = 0
if new_tokens > 0 then
new_tokens = new_tokens - 1
allowed = 1
end</p><p>redis.call('SET', tokens_key, new_tokens)
redis.call('SET', time_key, now)
redis.call('EXPIRE', tokens_key, expire)
redis.call('EXPIRE', time_key, expire)</p><p>return {allowed, new_tokens}</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis"><img
														src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Sentinal Redis" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis" class="overflowclass">Sentinal Redis</a>
													<p class="overflowclass">监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill11046" title="Sentinal Redis" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>

在控制器中调用：

$redis = \think\facade\Cache::store('redis')->handler();
$key = 'rate:api:' . $request->ip();
$capacity = 10;
$rate = 2; // 每秒补 2 个
$expire = 60;
<p>$result = $redis->eval($luaScript, [$key], [$capacity, $rate, $expire, time()]);
list($allowed, $left) = $result;</p><p>if (!$allowed) {
throw new HttpException(429, 'Too Many Requests');
}</p>

实际部署时容易忽略的三个点

很多人跑通了单机脚本就以为 OK，但上线后仍会超限或误拦截：

time() 在多台服务器上不同步 —— 必须统一用 microtime(true) 或 NTP 校准，不能依赖各机器本地时间
Redis 连接未设置 read_timeout 和 retry_interval，网络抖动时脚本执行失败，但业务没兜底，直接放行
key 设计没带用户/接口维度，比如用 rate:api 全局一把锁，导致一个用户刷崩整个接口；应至少含 $request->routeInfo()['rule'] 或 $request->header('X-Real-IP')

令牌桶真正的复杂点不在算法本身，而在时间精度、分布式一致性、以及失败路径是否真正阻断请求。Lua 脚本只是起点，后续还得加监控看 allowed 返回分布、定期清理过期 key、考虑突发流量时的预热策略。