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