一、經(jīng)典限流算法的深度對(duì)比與選型建議

關(guān)鍵差異總結(jié)

選型建議：

• 若追求極致性能且可接受“59秒+1秒”突發(fā) → 用 固定窗口；
• 若業(yè)務(wù)對(duì)流量平滑性要求嚴(yán)格，如防止刷 單、搶購(gòu) → 用 滑動(dòng)窗口 或 令牌桶；
• 若希望在突發(fā)情況下仍能放行一定數(shù)量請(qǐng)求，同時(shí)長(zhǎng)期速率受控 → 優(yōu)先選擇 令牌桶；
• 若下游是數(shù)據(jù)庫(kù)/文件系統(tǒng)等慢速資源，必須保證輸入速率穩(wěn)定 → 選 漏桶。

二、RedisCell 模塊詳解：官方推薦的“開箱即用”限流利器

為什么推薦使用 RedisCell？

命令詳解（結(jié)合實(shí)例）

# 示例：用戶 user123 每分鐘最多 15 次請(qǐng)求，突發(fā)容量 15，正常速率 1次/秒
CL.THROTTLE user123 15 60 1

返回值解析：

[1, 14, 0]   # 允許，剩余令牌 14，無(wú)需等待
[0, 15, 2]   # 拒絕，剩余令牌 15，需等待 2 秒后再試

• 1: 允許請(qǐng)求
• 0: 拒絕請(qǐng)求
• remaining_tokens: 當(dāng)前可用令牌數(shù)（可用于降級(jí)提示）
• delay: 如果拒絕，建議等待多少秒再嘗試（單位：秒）

注意：CL.THROTTLE 的 period 是以秒為單位，但內(nèi)部是以毫秒精度計(jì)算的，因此即使周期較短（如 1 秒），也能做到精確控制。

如何啟用 RedisCell？

確保 Redis 版本 ≥ 4.0；

修改 redis.conf 啟用模塊：

loadmodule /path/to/redis-cell.so

通常安裝 Redis 時(shí)會(huì)自帶該模塊（路徑可能為 /usr/lib/redis/modules/redis-cell.so）；

啟動(dòng)后可通過(guò) MODULE LIST 查看是否加載成功。

使用建議：

• 不要濫用 max_burst：雖然它提升了用戶體驗(yàn)，但可能導(dǎo)致下游瞬間壓力激增。
• 配合熔斷機(jī)制使用：當(dāng) delay 大于閾值（如 >3 秒），應(yīng)觸發(fā)熔斷或降級(jí)策略。
• 日志埋點(diǎn)：記錄被限流的請(qǐng)求，用于分析異常流量來(lái)源。

三、工程優(yōu)化與避坑指南（進(jìn)階篇）

1.原子性：必須用 Lua 腳本！

? 錯(cuò)誤做法（易出并發(fā)問(wèn)題）：

GET counter
IF count > limit: RETURN reject
INCR counter

→ 存在“競(jìng)態(tài)條件”，多個(gè)請(qǐng)求可能同時(shí)讀到 count=14，導(dǎo)致超限。

? 正確做法（使用 Lua 腳本）：

-- 令牌桶邏輯（簡(jiǎn)化版）
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2]) -- 令牌生成速度（個(gè)/秒）
local now = tonumber(ARGV[3])

local bucket = redis.call('HMGET', key, 'last_time', 'tokens')
local last_time = tonumber(bucket[1]) or 0
local tokens = tonumber(bucket[2]) or capacity

local delta = math.max(0, now - last_time)
local add_tokens = delta * rate
tokens = math.min(capacity, tokens + add_tokens)

if tokens >= 1 then
    tokens = tokens - 1
    redis.call('HMSET', key, 'last_time', now, 'tokens', tokens)
    return 1
else
    return 0
end

使用方式：

EVAL "lua_script" 1 user123 10 1 1700000000

優(yōu)勢(shì)：所有操作在一個(gè)事務(wù)中完成，無(wú)中間狀態(tài)暴露。

2.內(nèi)存治理：防止“數(shù)據(jù)堆積”

常見(jiàn)陷阱：

• 滑動(dòng)窗口使用 Zset：若不清理過(guò)期數(shù)據(jù)，會(huì)導(dǎo)致內(nèi)存持續(xù)增長(zhǎng)；
• 令牌桶使用 Hash：若用戶過(guò)多，且未設(shè)置合理過(guò)期時(shí)間，也會(huì)造成內(nèi)存泄漏；
• 漏桶使用 List：如果消費(fèi)者處理慢，隊(duì)列無(wú)限增長(zhǎng)。

解決方案：

最佳實(shí)踐：

# 滑動(dòng)窗口：每分鐘清理一次過(guò)期時(shí)間戳
SCHEDULED JOB:
    ZREMRANGEBYSCORE window_key -inf < (now - 60)

 強(qiáng)烈建議：將限流數(shù)據(jù)的 TTL 控制在合理范圍內(nèi)（如 1~2 小時(shí)），避免內(nèi)存爆炸。

3.分布式環(huán)境下的限流一致性

問(wèn)題：多個(gè)服務(wù)節(jié)點(diǎn)共享同一份 Redis，但各自緩存本地計(jì)數(shù) → 不一致！

? 解決方案：

切忌：在本地內(nèi)存做限流計(jì)數(shù)，除非配合 Redis 作為主源同步。

4.限流策略的可觀測(cè)性 & 監(jiān)控

限流不是“黑盒”，必須具備可觀測(cè)性：

必須采集的關(guān)鍵指標(biāo)：

推薦監(jiān)控方式：

• 將限流返回結(jié)果寫入日志（如 OpenTelemetry Trace）；
• 使用 Prometheus + Grafana 可視化限流率；
• 在網(wǎng)關(guān)層集成限流統(tǒng)計(jì)器，發(fā)送至 Metrics Server。

四、實(shí)戰(zhàn)場(chǎng)景推薦組合

五、總結(jié)：構(gòu)建健壯限流系統(tǒng)的黃金法則

附錄：常用限流命令速查表

最終建議：

在生產(chǎn)環(huán)境中，優(yōu)先使用 RedisCell，除非有特殊定制需求；

對(duì)于復(fù)雜場(chǎng)景，基于 Lua 腳本實(shí)現(xiàn)令牌桶/滑動(dòng)窗口，并加入監(jiān)控與自動(dòng)化清理機(jī)制；

所有策略都應(yīng)可配置、可觀察、可降級(jí)。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論