高并发API网关限流实战用Redisson从零构建分布式流量防护【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson深夜两点监控大屏突然飘红。你的下单接口 QPS 从 800 一路飙到 8000数据库连接池瞬间被打穿整条业务链路跟着雪崩。复盘时发现单机限流在水平扩容后形同虚设每个节点各限各的总量完全失控。这是很多团队都踩过的坑而解决方案就是给 API 网关装上Redisson 分布式限流这一层全局闸门。Redisson 是 Java 生态里基于 Redis/Valkey 的实时数据平台客户端它内置的 RRateLimiter 限流器可以把限流状态统一收敛到 Redis做到真正的全局精确。限流到底在限什么一个小区水箱的比喻想象一栋楼共用一个水箱进水管每小时只补 100 升。如果每户各自装水表、各管各的有人疯狂放水时邻居就只能干等更糟的是每户以为自己才用了 20 升可水箱早就空了。分布式限流要解决的就是这个各算各账的问题——把水位可用许可、放水记录已用许可都记在 Redis 这一个总表上所有节点查同一份数据。Redisson 的实现正是如此每次tryAcquire都会执行一段 Lua 脚本在 Redis 内部原子地完成查水位、扣许可、写记录三步期间没有任何并发窗口所以多实例抢许可也不会超发。这就是它和本地AtomicLong计数、单机 Guava RateLimiter 最本质的区别。三步上手安装、配置、验证整个落地过程不需要写任何自定义 Redis 命令Redisson 把底层 Lua 脚本全部封装好了。第 1 步引入依赖并建立客户端dependency groupIdorg.redisson/groupId artifactIdredisson/artifactId version3.27.2/version /dependencyConfig config new Config(); config.useSingleServer().setAddress(redis://127.0.0.1:6379); RedissonClient client Redisson.create(config); RRateLimiter limiter client.getRateLimiter(gw:rate:pay);每个限流器对应 Redis 里的一个键空间gw:rate:pay就是支付接口的专属水表。第 2 步设定规则并获取许可// 首次设置生效若该 key 已存在规则返回 false不会误覆盖 limiter.trySetRate(RateType.OVERALL, 100, Duration.ofSeconds(1)); // 尝试拿 1 个许可最多等 200ms拿不到立刻返回 false boolean ok limiter.tryAcquire(1, Duration.ofMillis(200)); if (ok) { chain.doFilter(request, response); // 放行 } else { response.setStatus(429); // 拒绝并提示限流 }第 3 步在网关过滤器里验证效果用一个普通的 Servlet Filter 即可验证无需引入网关框架WebFilter(/pay/*) public class RateGuardFilter implements Filter { private final RRateLimiter limiter ...; // 注入同一个限流器 public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) { if (limiter.tryAcquire()) { chain.doFilter(req, res); } else { ((HttpServletResponse) res).setStatus(429); } } }用压测工具打 200 QPS 持续 5 秒观察响应码分布约 500 个请求得到 200其余全部 429且多开两个实例压测总放行量依然稳定在 100/秒——全局限流生效。✅避坑指南新手最容易踩的 4 个限流坑报错/异常现象产生原因解决方案trySetRate始终返回 false规则早已存在该方法只在首次创建时生效确认是否需要覆盖改用setRate强制重置明明限了流总量还是超误用PER_CLIENT每个实例各自独立额度全局兜底一律用OVERALL接口偶尔卡顿几秒调用了阻塞版acquire()无超时地死等许可换成带Duration的tryAcquireRedis 里限流 key 无限堆积从未设置keepAliveTime键永不清理设置限流器 TTL闲置自动回收⚠️ 特别注意trySetRate和setRate语义完全不同前者有则不设、后者无脑覆盖并清空状态。上线脚本里用错会把线上规则悄悄改掉。性能与选型三种限流方案横评方案全局一致性单次耗时部署成本适用场景本地计数器 / Guava❌ 各节点独立纳秒级零单机兜底、非关键路径网关中间件如 Sentinel 控制台✅毫秒级需独立控制台已有中间件体系的团队Redisson RRateLimiter✅毫秒级含 1 次 Redis RTT仅依赖已有 Redis多实例服务、API 网关、秒杀 结论如果你的 Redis 已经在用Redisson 限流是性价比最高的方案——不引入新组件只多一次 Redis 往返。若要极限压性能可结合本地预取做两级限流但这属于高阶优化一般场景不必。进阶玩法让限流从能用到聪明① 动态调速应对流量峰谷。大促开始时把额度从 100 提到 500活动结束再降回来limiter.setRate(RateLimiterArgs.of(RateType.OVERALL, 500, Duration.ofSeconds(1)));② 给限流器加上生命周期。keepAliveTime让闲置限流器自动过期updateRate配合keepState(true)还能在改规则的同时保留已用记录避免瞬间清零造成流量毛刺。③ 批量与异步双通道。批量接口用acquire(10)一次占 10 个许可高并发线程里用tryAcquireAsync配合回调避免阻塞业务线程limiter.tryAcquireAsync(1).whenComplete((ok, err) - { if (ok) { /* 放行逻辑 */ } else { /* 429 逻辑 */ } });行动清单把全局闸门装进你的系统选定一个核心接口用getRateLimiter创建限流器并设好初始规则用带超时的tryAcquire替换所有阻塞调用压测验证多实例下的全局总量确认OVERALL生效为所有限流器配置keepAliveTime防止键堆积把限流埋点接入监控观察 429 占比随时间变化那晚的事故之后我给网关所有入口都接上了 Redisson 限流。如今再遇流量洪峰最先报警的不再是数据库而是那扇闸门自己——流量可以被拒绝但系统绝不会被打垮。想深入源码可直接 clone 仓库https://gitcode.com/GitHub_Trending/re/redisson查看RedissonRateLimiter、RRateLimiter、RateLimiterArgs三个核心文件官方文档见docs/data-and-services/objects.md与docs/commands-mapping.md限流的完整方法清单都在其中。【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 高并发API网关限流实战：用Redisson从零构建分布式流量防护
高并发API网关限流实战用Redisson从零构建分布式流量防护【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson深夜两点监控大屏突然飘红。你的下单接口 QPS 从 800 一路飙到 8000数据库连接池瞬间被打穿整条业务链路跟着雪崩。复盘时发现单机限流在水平扩容后形同虚设每个节点各限各的总量完全失控。这是很多团队都踩过的坑而解决方案就是给 API 网关装上Redisson 分布式限流这一层全局闸门。Redisson 是 Java 生态里基于 Redis/Valkey 的实时数据平台客户端它内置的 RRateLimiter 限流器可以把限流状态统一收敛到 Redis做到真正的全局精确。限流到底在限什么一个小区水箱的比喻想象一栋楼共用一个水箱进水管每小时只补 100 升。如果每户各自装水表、各管各的有人疯狂放水时邻居就只能干等更糟的是每户以为自己才用了 20 升可水箱早就空了。分布式限流要解决的就是这个各算各账的问题——把水位可用许可、放水记录已用许可都记在 Redis 这一个总表上所有节点查同一份数据。Redisson 的实现正是如此每次tryAcquire都会执行一段 Lua 脚本在 Redis 内部原子地完成查水位、扣许可、写记录三步期间没有任何并发窗口所以多实例抢许可也不会超发。这就是它和本地AtomicLong计数、单机 Guava RateLimiter 最本质的区别。三步上手安装、配置、验证整个落地过程不需要写任何自定义 Redis 命令Redisson 把底层 Lua 脚本全部封装好了。第 1 步引入依赖并建立客户端dependency groupIdorg.redisson/groupId artifactIdredisson/artifactId version3.27.2/version /dependencyConfig config new Config(); config.useSingleServer().setAddress(redis://127.0.0.1:6379); RedissonClient client Redisson.create(config); RRateLimiter limiter client.getRateLimiter(gw:rate:pay);每个限流器对应 Redis 里的一个键空间gw:rate:pay就是支付接口的专属水表。第 2 步设定规则并获取许可// 首次设置生效若该 key 已存在规则返回 false不会误覆盖 limiter.trySetRate(RateType.OVERALL, 100, Duration.ofSeconds(1)); // 尝试拿 1 个许可最多等 200ms拿不到立刻返回 false boolean ok limiter.tryAcquire(1, Duration.ofMillis(200)); if (ok) { chain.doFilter(request, response); // 放行 } else { response.setStatus(429); // 拒绝并提示限流 }第 3 步在网关过滤器里验证效果用一个普通的 Servlet Filter 即可验证无需引入网关框架WebFilter(/pay/*) public class RateGuardFilter implements Filter { private final RRateLimiter limiter ...; // 注入同一个限流器 public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) { if (limiter.tryAcquire()) { chain.doFilter(req, res); } else { ((HttpServletResponse) res).setStatus(429); } } }用压测工具打 200 QPS 持续 5 秒观察响应码分布约 500 个请求得到 200其余全部 429且多开两个实例压测总放行量依然稳定在 100/秒——全局限流生效。✅避坑指南新手最容易踩的 4 个限流坑报错/异常现象产生原因解决方案trySetRate始终返回 false规则早已存在该方法只在首次创建时生效确认是否需要覆盖改用setRate强制重置明明限了流总量还是超误用PER_CLIENT每个实例各自独立额度全局兜底一律用OVERALL接口偶尔卡顿几秒调用了阻塞版acquire()无超时地死等许可换成带Duration的tryAcquireRedis 里限流 key 无限堆积从未设置keepAliveTime键永不清理设置限流器 TTL闲置自动回收⚠️ 特别注意trySetRate和setRate语义完全不同前者有则不设、后者无脑覆盖并清空状态。上线脚本里用错会把线上规则悄悄改掉。性能与选型三种限流方案横评方案全局一致性单次耗时部署成本适用场景本地计数器 / Guava❌ 各节点独立纳秒级零单机兜底、非关键路径网关中间件如 Sentinel 控制台✅毫秒级需独立控制台已有中间件体系的团队Redisson RRateLimiter✅毫秒级含 1 次 Redis RTT仅依赖已有 Redis多实例服务、API 网关、秒杀 结论如果你的 Redis 已经在用Redisson 限流是性价比最高的方案——不引入新组件只多一次 Redis 往返。若要极限压性能可结合本地预取做两级限流但这属于高阶优化一般场景不必。进阶玩法让限流从能用到聪明① 动态调速应对流量峰谷。大促开始时把额度从 100 提到 500活动结束再降回来limiter.setRate(RateLimiterArgs.of(RateType.OVERALL, 500, Duration.ofSeconds(1)));② 给限流器加上生命周期。keepAliveTime让闲置限流器自动过期updateRate配合keepState(true)还能在改规则的同时保留已用记录避免瞬间清零造成流量毛刺。③ 批量与异步双通道。批量接口用acquire(10)一次占 10 个许可高并发线程里用tryAcquireAsync配合回调避免阻塞业务线程limiter.tryAcquireAsync(1).whenComplete((ok, err) - { if (ok) { /* 放行逻辑 */ } else { /* 429 逻辑 */ } });行动清单把全局闸门装进你的系统选定一个核心接口用getRateLimiter创建限流器并设好初始规则用带超时的tryAcquire替换所有阻塞调用压测验证多实例下的全局总量确认OVERALL生效为所有限流器配置keepAliveTime防止键堆积把限流埋点接入监控观察 429 占比随时间变化那晚的事故之后我给网关所有入口都接上了 Redisson 限流。如今再遇流量洪峰最先报警的不再是数据库而是那扇闸门自己——流量可以被拒绝但系统绝不会被打垮。想深入源码可直接 clone 仓库https://gitcode.com/GitHub_Trending/re/redisson查看RedissonRateLimiter、RRateLimiter、RateLimiterArgs三个核心文件官方文档见docs/data-and-services/objects.md与docs/commands-mapping.md限流的完整方法清单都在其中。【免费下载链接】redissonRedisson: Valkey Redis Java Client and Real-Time Data Platform. Sync/Async/RxJava/Reactive API. Over 50 Valkey and Redis based Java objects and services: Set, Multimap, SortedSet, Map, List, Queue, Deque, Semaphore, Lock, AtomicLong, Map Reduce, Bloom filter, Spring, Tomcat, Scheduler, JCache API, Hibernate, RPC, local cache..项目地址: https://gitcode.com/GitHub_Trending/re/redisson创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考