限流這事單機(jī)好做分布式做起來就麻煩。你手里的Tomcat在單機(jī)上用Guava RateLimiter或者直接用Semaphore玩得再花也只是進(jìn)程內(nèi)有效。一旦服務(wù)拆成多實例流量被網(wǎng)關(guān)分?jǐn)偟讲煌?jié)點每個實例自己認(rèn)為“沒超限”加起來卻把下游數(shù)據(jù)庫、第三方接口、短信通道直接打爆。這時候就得把限流狀態(tài)放到一個所有實例都能訪問的地方——Redis 就是最合適的那個“共享賬本”。Redisson 的 RateLimiter 是 Java 生態(tài)里做得比較省心的一個方案。它不像你自己寫 Lua 腳本去操作 Redis 那樣容易踩原子性的坑也不像引入 Sentinel 那樣需要額外部署控制臺、維護(hù)規(guī)則文件。Redisson 把令牌桶算法封裝成了開箱即用的 RRateLimiter一行代碼初始化一行代碼判斷通過還是拒絕底層用 Lua 腳本保證分布式環(huán)境下的原子性。這篇內(nèi)容我會把它的原理、參數(shù)、業(yè)務(wù)落地以及我實際踩過的幾個坑一起講清楚適合正在做服務(wù)拆分的后端開發(fā)、想給接口加限流但不想再造輪子的人參考。1. 為什么選 Redis 做限流落點而不是本地限流或網(wǎng)關(guān)限流1.1 先分清三種限流方式的邊界限流這件事首先要明確一個基礎(chǔ)問題你到底要限制誰的流量是限制單個請求處理進(jìn)程還是限制整個服務(wù)集群還是要限制某個網(wǎng)關(guān)入口不同的答案會直接決定你用什么存儲和算法。最樸素的做法是本地限流。每個服務(wù)實例維護(hù)自己的計數(shù)器用AtomicLong或者 Guava 的RateLimiter。優(yōu)點是一點額外的網(wǎng)絡(luò)開銷都沒有性能極高缺點是實例之間互不相通。假設(shè)你有 4 個節(jié)點每個節(jié)點限流 100 QPS整體服務(wù)能力就是 400 QPS看起來沒問題。但流量分配經(jīng)常是不均勻的某臺機(jī)器可能瞬間收到 150 QPS另一臺只收到 50 QPS結(jié)果一臺拒絕請求另一臺卻在閑置。這時候本地限流就變成了“偽限流”整體閾值根本控制不住。網(wǎng)關(guān)限流是另一種常見做法。Spring Cloud Gateway、Nginx、API 網(wǎng)關(guān)這一層做的限流好處是集中所有流量都過這里規(guī)則統(tǒng)一適合入口層面的粗粒度控制。問題在于網(wǎng)關(guān)層通常只做路徑級或 IP 級的限流拿不到業(yè)務(wù)上下文比如當(dāng)前用戶 ID 是什么、訂單金額多大真要按業(yè)務(wù)維度精細(xì)化限流還得回到應(yīng)用層來做。Redis 做分布式限流的邏輯就清晰了。所有實例共享同一個 Redis key誰來了誰去這個 key 上做“記賬”Token 足夠就放行、不夠就拒絕。實例數(shù)量增加時不需要改代碼只需要保證它們連的是同一個 Redis 就行。但這里有個關(guān)鍵點Redis 是不可靠的它本身不提供嚴(yán)格的事務(wù)和持久化所以你要把 Redis 當(dāng)成一個“高性能計數(shù)器存儲”而不是“數(shù)據(jù)庫”所有復(fù)雜邏輯必須用 Lua 腳本原子執(zhí)行防止并發(fā)讀寫不一致。1.2 分布式限流方案橫向?qū)Ρ葟膶崿F(xiàn)方案粒度上看我見過的大致有這幾類方案實現(xiàn)難度原子性保障可維護(hù)性適合場景自己寫 Redis Lua高取決于腳本質(zhì)量低腳本難調(diào)試公司不允許引入額外依賴、需要定制算法Redisson RateLimiter低內(nèi)置 Lua可靠高API 清晰大多數(shù)業(yè)務(wù)接口限流、搶購、防刷Sentinel中高依賴數(shù)據(jù)源適配中需要控制臺和規(guī)則持久化需要流控熔斷系統(tǒng)自適應(yīng)保護(hù)的全方位場景網(wǎng)關(guān)限流低高高入口級限流、IP 防刷如果你只需要一個輕量的、代碼侵入小的限流工具Redisson 是最平衡的選擇。它不需要你自己設(shè)計 Redis key 存幾個字段、不需要你手寫 Lua 判斷“上次補(bǔ)充令牌到現(xiàn)在過去了多少毫秒”、不需要你考慮腳本被 Redis 拒絕執(zhí)行的情況這些 Redisson 全做了。而且 Redisson 本身就自帶 Redis 連接池、重試、讀寫分離等能力相當(dāng)于你只是順手用了它一個子模塊連接管理沒有額外負(fù)擔(dān)。2. Redisson RateLimiter 核心原理拆解2.1 令牌桶算法在 Redis 里的落地形態(tài)Redisson 的 RateLimiter 是基于令牌桶算法實現(xiàn)的。令牌桶的核心思想不用我多解釋桶里最多存 N 個令牌每來一個請求就取一個令牌取不到就拒絕同時有個“補(bǔ)充器”按固定速率往桶里加令牌。關(guān)鍵在于兩條規(guī)則加令牌速率固定但加令牌的動作不是每毫秒都做的真實實現(xiàn)是“懶加載”——第一次請求時算一下距離上次補(bǔ)充過去了多久這段時間該加幾個令牌一次性加上去。桶有上限令牌不能無限累積超過桶容量就丟棄。在單機(jī)操作這個邏輯很簡單搞兩個變量lastRefillTime和tokens用 synchronized 或者一個 ConcurrentHashMap 的 compute 方法就搞定。但分布式環(huán)境下這兩個變量存在 Redis 里而且可能存在多個客戶端同時修改這就必須把“讀取、計算、回寫”三個步驟原子化。Redisson 的做法是寫 Lua 腳本把整段判斷邏輯放進(jìn) Redis 端執(zhí)行執(zhí)行完成后再返回客戶端。舉個例子哈希結(jié)構(gòu)里的 key 一般長這樣rate_limiter_xxx: { rate, interval, type, last_refill_time, tokens }Lua 腳本的執(zhí)行步驟大致是讀取當(dāng)前時間和上次補(bǔ)充時間計算時間差按速率補(bǔ)充令牌到桶里上限 rate 個判斷是否還有剩余令牌有則扣減并返回 1無則返回 0。整個過程在 Redis 單線程模型下執(zhí)行天然具有互斥性這才保證了分布式環(huán)境下的數(shù)字準(zhǔn)確。2.2 核心 API 與參數(shù)語義Redisson 提供的關(guān)鍵接口是RRateLimiter創(chuàng)建方式也很直接RRateLimiter rateLimiter redissonClient.getRateLimiter(order:create:limit);拿到之后有兩個必做操作初始化和請求。初始化方法trySetRateboolean success rateLimiter.trySetRate( RateType.OVERALL, // 限流模式 10, // 速率單位是“允許的請求數(shù)” 1, // 時間跨度 RateIntervalUnit.SECONDS // 時間單位 );這里兩個參數(shù)最容易被忽略。第一個是RateType它有兩個取值OVERALL表示整個集群總共限制 10 個請求每秒這個模式是真正的“全局限流”發(fā)給任何實例的請求都會去爭搶同一個令牌池PER_CLIENT表示每個客戶端每個 Redis 連接各自獨(dú)立限流某種意義上它退回了單機(jī)限流的邏輯適合某些對單個實例吞吐有要求的場景但一般分布式限流用不到。第二個是時間跨度和速率的組合rate10, interval1, unitSECONDS就是每秒鐘補(bǔ) 10 個令牌桶容量也是 10。請求方法有三種模式我用過之后的理解是// 非阻塞式?jīng)]令牌就立刻返回 false推薦用于需要快速響應(yīng)的接口 boolean shouldAllow rateLimiter.tryAcquire(); // 帶等待時間沒令牌就阻塞等待最多 3 秒3 秒內(nèi)等到令牌則返回 true boolean shouldAllow rateLimiter.tryAcquire(3, TimeUnit.SECONDS); // 阻塞式一直等到有令牌為止慎用可能長時間占住線程 rateLimiter.acquire();tryAcquire還有一個重載方法tryAcquire(int permits)可以一次拿多個令牌比如一個請求可能需要消耗多個“配額”這在某些批量任務(wù)場景會用到但要提醒一句一次性申請多個令牌時如果桶里只有部分額度Redisson 的做法不是拆開拿一部分然后回寫剩余部分而是整筆拒絕邏輯上要清楚這點。2.3 從源碼視角看調(diào)用鏈路你自己看 Redisson 源碼時可以從RedissonRateLimiter類入手。它內(nèi)部的tryAcquire最終會調(diào)用tryAcquireAsync然后調(diào)用get(RedisCommands.EVAL_LIST)把 Lua 腳本送到 Redis。Lua 腳本片段是寫死在類常量里的核心邏輯基本是這樣我做了脫敏簡化-- 從 hash 中讀取當(dāng)前時間、上次補(bǔ)充時間、當(dāng)前令牌數(shù) local last_refill_time redis.call(hget, KEYS[1], last_refill_time) local tokens redis.call(hget, KEYS[1], tokens) -- 計算可以補(bǔ)充的令牌總數(shù) local delta (now - last_refill_time) / interval local new_tokens math.min(rate, tokens delta * rate) -- 如果剩余令牌大于等于申請的 permits則通過并扣減 if new_tokens permits then redis.call(hset, KEYS[1], tokens, new_tokens - permits) redis.call(hset, KEYS[1], last_refill_time, now) return 1 else return 0 end我特意提源碼是因為理解了底層腳本之后很多問題都能推斷出答案。比如你可能會問“為什么我設(shè)置了 10 QPS但偶爾會連續(xù)通過 20 個請求”——這和令牌桶算法的“桶容量”有關(guān)。trySetRate(10, 1, SECONDS)的桶容量是 10這意味著 1 秒內(nèi)最多通過 10 個但如果上一秒完全沒有流量桶里積攢了完整的 10 個令牌那么這個瞬間 burst 流量是可以一次吃掉的。如果你不想要 burst需要設(shè)置rate和interval組合使得桶容量變小或者干脆用RateType.PER_CLIENT做更嚴(yán)格的限制。3. Spring Boot 工程化落地3.1 基礎(chǔ)設(shè)施準(zhǔn)備與依賴引入先準(zhǔn)備環(huán)境。我這里用 Redis 6.x 及以上版本Redisson 3.20。Docker 起一個簡單的 Redisdocker run -d --name redis-local \ -p 6379:6379 \ -e REDIS_PASSWORDyourpassword \ redis:7.0 \ redis-server --requirepass yourpassword然后引入依賴。你是 Spring Boot 項目的話建議直接用spring-boot-starter-data-redis之外的 Redisson 專屬 starterdependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.23.5/version /dependency這個 starter 會自動裝配 RedissonClient但連接配置你可以用默認(rèn)spring.data.redis.*的配置也可以單獨(dú)寫 Redisson 配置類。推薦單獨(dú)寫因為限流組件對連接池的關(guān)注點和緩存不太一樣限流場景下連接池容易被打滿最好單獨(dú)調(diào)參數(shù)。spring: redis: host: 127.0.0.1 port: 6379 password: yourpassword redisson: config: singleServerConfig: address: redis://127.0.0.1:6379 password: yourpassword connectionMinimumIdleSize: 10 connectionPoolSize: 64 idleConnectionTimeout: 10000 pingConnectionInterval: 600003.2 限流組件的工程實現(xiàn)一個比較規(guī)范的落地方式是封裝一個限流服務(wù)統(tǒng)一管理 RateLimiter 的創(chuàng)建、初始化和判斷邏輯而不是在業(yè)務(wù)代碼里直接操作RedissonClient。原因很簡單getRateLimiter每次獲取的 handle 最好是同一個且在trySetRate之前要先比較現(xiàn)有配置是否一致否則可能出現(xiàn)并發(fā)情況下重復(fù)初始化導(dǎo)致限流器數(shù)據(jù)被重置的尷尬場景。我建議的封裝代碼大致如下Component public class RateLimiterService { private final RedissonClient redissonClient; private final MapString, RRateLimiter limiterCache new ConcurrentHashMap(); public RateLimiterService(RedissonClient redissonClient) { this.redissonClient redissonClient; } public boolean tryAcquire(String key, double permits) { RRateLimiter rRateLimiter getOrCreateLimiter(key); // 這里可以分別對不同 key 使用不同配置也可以統(tǒng)一在一個方法里傳入 return rRateLimiter.tryAcquire(1); } private RRateLimiter getOrCreateLimiter(String key) { return limiterCache.computeIfAbsent(key, k - redissonClient.getRateLimiter(ratelimiter: k)); } public void initAndSetRate(String key, long rate, long interval, RateIntervalUnit unit) { limiterCache.computeIfAbsent(key, k - { RRateLimiter rRateLimiter redissonClient.getRateLimiter(ratelimiter: k); // 只在空車情況下初始化 rRateLimiter.trySetRate(RateType.OVERALL, rate, interval, unit); return rRateLimiter; }); } }這里我有個小改動tryAcquire方法參數(shù)用的是double permits這是因為 Redisson 的 API 本身是支持小數(shù)令牌的比如配額不足時可以只申請 0.5 個令牌適用于某些按比例限制請求的場景。但實際業(yè)務(wù)里絕大多數(shù)人只需要1所以保留靈活度即可。與代碼配套的一個工具是基于注解的方式接入業(yè)務(wù)方法。這種模式對業(yè)務(wù)代碼的侵入幾乎為零適合你不想在每個 Controller 方法里都寫if (!rateLimiterService.tryAcquire(userId, 1)) throw...的情況。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface DistributedRateLimit { String key(); long rate(); long interval() default 1; RateIntervalUnit unit() default RateIntervalUnit.SECONDS; }再配合一個HandlerInterceptor或者 AOP 切面攔截標(biāo)注了注解的 Controller 方法。AOP 的寫法大概是Aspect Component public class RateLimitAspect { private final RateLimiterService rateLimiterService; Around(annotation(distributedRateLimit)) public Object around(ProceedingJoinPoint joinPoint, DistributedRateLimit distributedRateLimit) throws Throwable { String key distributedRateLimit.key(); // 可以結(jié)合 Spel 解析參數(shù)動態(tài)生成 key if (!rateLimiterService.tryAcquire(key, 1)) { throw new RateLimitException(系統(tǒng)繁忙請稍后重試); } return joinPoint.proceed(); } }這么做的直接好處是業(yè)務(wù)代碼只管自己的邏輯限流規(guī)則放在注解里聲明人要做的變更就是加一行DistributedRateLimit的事。團(tuán)隊協(xié)作時限流規(guī)則一眼就能看到不用翻代碼找漏了哪個接口沒限流。3.3 業(yè)務(wù)場景示例搶購接口保護(hù)這里寫一個比較實際的場景。假設(shè)一個秒殺接口活動開始時流量陡然上升但庫存只有 100 件你真實需要保護(hù)的能力不是接口本身而是下游庫存扣減服務(wù)和訂單創(chuàng)建服務(wù)。這類場景我的經(jīng)驗是做兩層限流第一層網(wǎng)關(guān)或入口層限制整個秒殺入口的 QPS比如 5000 QPS防止任何流量進(jìn)來都打到應(yīng)用。第二層應(yīng)用層用 Redisson RateLimiter 做精確值的業(yè)務(wù)限流比如每秒只允許 1000 個請求去查庫存、每秒只允許 50 個請求真正落單。為了說明這一點我舉個例子。RestController RequestMapping(/api/seckill) public class SeckillController { private final RateLimiterService rateLimiterService; GetMapping(/sku/{skuId}/check) public Result checkStock(PathVariable Long skuId, User user) { // 按 SKU 維度控制查詢占比每秒最多 1000 次 boolean allow rateLimiterService.tryAcquire(seckill:check: skuId, 1); if (!allow) { return Result.error(429, 活動火爆請稍后重試); } // 正常查庫存邏輯 } PostMapping(/sku/{skuId}/order) public Result createOrder(PathVariable Long skuId, User user) { boolean allow rateLimiterService.tryAcquire(seckill:order: skuId, 1); if (!allow) { return Result.error(429, 下單人數(shù)過多請稍后重試); } // 正常下單邏輯 } }注意到我用了一個技巧把業(yè)務(wù)請求分成“查庫存”和“下單”兩個 key 來控制兩者消耗的令牌池互不影響避免查庫存流量把下單的令牌全部搶光。4. 踩坑記錄與排查技巧4.1 我遇到過的六個高頻問題做限流器這件事最容易出問題的往往不是不會用 API而是對分布式環(huán)境的假設(shè)有偏差。我列幾個自己踩過的坑以及從別人代碼里見到過的問題問題現(xiàn)象根本原因解決方案設(shè)置了 10 QPS但出現(xiàn)連續(xù) 20 個請求通過令牌桶的桶容量就是 rate 的值burst 流量累積如果不想允許突發(fā)把rate調(diào)小或配合tryAcquire的等待參數(shù)抑制突發(fā)trySetRate 返回 false但限流不生效限流器 key 之前已經(jīng)初始化過重復(fù)設(shè)置不會覆蓋配置啟動時統(tǒng)一初始化避免每個實例各自初始化Redis 連接超時連接池太小限流器在高并發(fā)下把連接打滿調(diào)大connectionPoolSize并開啟pingConnectionInterval保持心跳限流閾值實際上是 N 倍的預(yù)期值每個服務(wù)實例都調(diào)用了trySetRate初始化但不同實例 config 不一致讓初始化動作收斂到某個統(tǒng)一入口或者用同一個 Redis key 且所有實例統(tǒng)一入?yún)ryAcquire(10) 總是失敗一次性申請多個令牌時會要求桶內(nèi)必須滿足全部數(shù)量不支持“部分成功”按單個 permits 循環(huán)調(diào)用或者業(yè)務(wù)上拆分成多批次限流 key 永久占用 Redis 內(nèi)存動態(tài) key 越來越多比如按用戶維度限流每個用戶一個 key結(jié)合redissonClient.getKeys().setExpire()給動態(tài) key 設(shè)置 TTL第三個問題我想多說一句。很多人把限流器用掛了不是算法不對而是 Redis 連接池被打爆。限流本身是在高流量場景下才會觸發(fā)的如果接口 QPS 到了 5000你每次請求都要做一次 Redis 命令往返默認(rèn)的 24 個連接是遠(yuǎn)遠(yuǎn)不夠的。我一般會把connectionPoolSize調(diào)整為 64 或 128同時給這個專門的 RedisClient 單獨(dú)一個連接池配置不跟緩存共用。4.2 性能與容量規(guī)劃聊性能之前先算一筆賬。一次tryAcquire是一次 Redis eval 命令大部分網(wǎng)絡(luò)環(huán)境下 RTT 在 0.5ms 到 1ms 之間。假設(shè)你的接口限流閾值是 1000 QPS那意味著每秒最多 1000 次 Redis 操作這個量對于 Redis 來說毫無壓力。但如果限流接口的訪問量是 10 萬 QPS 而最終只能通過 1000 個請求剩下的 99000 個請求也要各發(fā)起一次tryAcquire這些 Redis 操作對單節(jié)點來說是能抗住的但會占用連接和網(wǎng)絡(luò)帶寬。所以我的經(jīng)驗是在流量較大的場景下盡量把限流器前置。比如可以先在網(wǎng)關(guān)層用一個粗粒度的限流擋住整體流量再在應(yīng)用層用 Redisson 做精細(xì)控制。這樣能減少無謂的 Redis 調(diào)用。此外如果你的 Redis 是集群模式要注意限流 key 對應(yīng)的 slot所有讀寫流量都打在一個 key 上可能造成熱 key 問題。此時可以分散 key或者做容量延伸比如“用戶維度限流”就天然分散到不同 key不容易熱。4.3 參數(shù)選擇建議與業(yè)務(wù)配合限流參數(shù)怎么給才合理我認(rèn)為沒有標(biāo)準(zhǔn)公式但有三個參考維度保護(hù)下游能力如果下游數(shù)據(jù)庫最多能扛 200 QPS那么接口限流就應(yīng)該設(shè)為 80% 的冗余上限約 160 QPS這個數(shù)是在壓測基礎(chǔ)上定的不是拍腦袋。用戶體驗對于普通查詢接口限流閾值太低容易誤傷正常用戶建議設(shè)置一個略高于峰值均值低于風(fēng)險上限的值。集群容量N 個節(jié)點的情況下如果你用OVERALL模式限流總量是集群的如果用PER_CLIENT實際總量會變成 N 倍。這個差別在配置時一定要想清楚我見過最典型的配置事故就是上線時用了PER_CLIENT以為線上限流是 100 QPS實際 4 節(jié)點打完變成 400 QPS。首次配好參數(shù)后建議上線前至少做一輪簡單的 Jmeter 或 wrk 壓測。壓測重點看兩個指標(biāo)一是限流值附近請求的通過率抖動大不大二是 Redis 的 QPS 和延遲有沒有異常。如果通過率劇烈抖動多半是配置項interval太小導(dǎo)致令牌補(bǔ)充粒度太粗可以臨時把rate調(diào)大一點或者改用tryAcquire(waitTime)讓部分請求等待一下。5. 一些實用經(jīng)驗總結(jié)最后把我在實際項目中打磨出來的幾條經(jīng)驗寫在這里不一定都在官方文檔里能看到。第一限流邏輯一定要活得夠久別在業(yè)務(wù)方法內(nèi)部里new RedissonClient。我在一個老項目里見過有人每來一個請求就創(chuàng)建一次RRateLimiter結(jié)果對象每次都是新的Redis key 也被反復(fù)初始化限流等于沒做。正確的是容器初始化階段就創(chuàng)建好通過依賴注入拿到單例。第二異常處理不要直接吞掉。Redis 臨時不可達(dá)的時候限流器會拋異常如果你的代碼是tryAcquire異常后默認(rèn)放行那么限流器在故障期間就完全失效反之如果默認(rèn)拒絕那 Redis 掛了你的服務(wù)也跟著掛。我的建議是做一個“快速失敗開關(guān)”Redis 不可達(dá)時拋出RateLimitUnavailableException由全局異常處理器決定是返回默認(rèn)值還是快速失敗絕對不要讓業(yè)務(wù)默默往 Redis 寫壞數(shù)據(jù)。第三限流 key 的命名要有統(tǒng)一前綴和業(yè)務(wù)語義。不要用沒有含義的隨機(jī) ID否則排查問題的時候redis-cli 里看到一堆 key 完全沒有頭緒。我的習(xí)慣是ratelimiter:{biz_module}:{scene}:{resource_id}比如ratelimiter:seckill:order:sku123。這樣不僅好排查還能順勢做容量清理。第四別把限流和防刷混為一談。限流解決的是系統(tǒng)容量問題防刷解決的是用戶惡意行為問題。限流器是保護(hù)系統(tǒng)不被過量請求拖垮防刷則需要更復(fù)雜的用戶行為分析和 IP 指紋。單一靠限流器去“防刷”會導(dǎo)致正常用戶的體驗被砍而真正的刷子只需要多換幾個 IP 或者調(diào)整頻率就能繞過。實際操作里我還養(yǎng)成了一個習(xí)慣每次上線新的限流策略都會在監(jiān)控面板里同時盯三個數(shù)據(jù)曲線一個是限流拒絕量一個是被限流接口的平均響應(yīng)時間一個是 Redis 本身的 OPS。拒絕量突增但接口 RT 沒有變化說明限流配置有誤傷拒絕量正常但 RT 有抖動可能是 Redis 集群出問題或者 waitTime 配置過長導(dǎo)致線程掛起。多張圖對著看比單看任何一張都容易定位問題。限流器這東西不怕配置不夠精細(xì)就怕上線后沒人管。Redisson 的 API 設(shè)計已經(jīng)足夠平滑你要做的就是把參數(shù)選對、把 key 管好、把 Redis 連接池養(yǎng)足。踩過幾次坑之后你會體會到分布式限流真正的難點不在于“如何寫一個限流器”而在于“如何讓限流器在業(yè)務(wù)中不至于誤傷用戶”。這一點靠的是對業(yè)務(wù)流量的理解而不是對框架 API 的熟練程度。