资讯动态

Redisson 分布式限流完整指南:4 步守住秒杀 API,扛住 300 倍流量洪峰

发布时间:2026/9/5 20:54:14 来源:尧图企业网站定制
Redisson 分布式限流完整指南4 步守住秒杀 API扛住 300 倍流量洪峰【免费下载链接】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/redissonRedisson 是 Valkey/Redis 的 Java 客户端自带 50 多种分布式服务。本文用 RRateLimiter 对象搭一套 Redisson 分布式限流的网关防线专治秒杀与爬虫把后端打挂的场面。秒杀开闸 10 分钟不限流会付出什么代价先讲一个真实感很强的事故某电商 0 点开抢一款限量手机正常 QPS 约 50开闸瞬间冲到 15000。没有网关限流的情况下10 分钟内发生了连锁反应订单接口把数据库连接池全部占满慢查询排队到 3 秒以上库存服务被拖垮健康检查失败被负载均衡摘除又拉回反复抖动网关自身线程池耗尽连查询物流这类无关接口也开始超时最终整个站点不可用而真正下单的只有 500 台机器。关键结论洪峰流量的 99% 本来就不该被处理。你的系统只需要放行那 500 台机器需要的请求其余的礼貌地挡掉就行。挡在门口这个动作就是 API 网关限流要干的事。RedissonRateLimiter 的许可模型3 分钟看懂令牌桶Redisson 把限流封装成RRateLimiter对象底层是令牌桶模型但桶不在任何一台网关的内存里而是放在 Redis 中。所有请求取令牌的动作都会执行同一段原子 Lua 脚本谁先执行谁先拿到许可。用一张时序图看两个网关实例共享一个桶三个要点说清楚机制不用看源码也能懂桶容量 你配置的每区间许可数。比如每 1 秒 500 个许可桶上限就是 500每个时间区间上一轮已用的许可会被自动收回桶重新变满。所以它是限速不是总量配额桶在 Redis不在进程里。这是分布式三个字的来源——10 台网关共用一个 500/s 的额度总量不会随实例数翻倍反之如果每台机器本地计数扩容一次限流阈值就悄悄变 10 倍这是本地限流最常见的翻车点。4 步配置全局限流连接、设速率、取许可、拒绝响应下面是一条最小可运行链路。演示路径刻意避开了初始化即设速率的惯性写法改用可重复执行的设速率方式后面讲动态调速时会用到。第 1 步连接 Redis 并拿到限流器。名字就是 Redis 里的键不同接口用不同名字各限各的Config config new Config(); config.useSingleServer().setAddress(redis://127.0.0.1:6379); RedissonClient redisson Redisson.create(config); // 秒杀下单接口的限流器键名带业务前缀 RRateLimiter limiter redisson.getRateLimiter(flash:order:rate);第 2 步设定速率。setRate任何时候都能调用、直接覆盖旧值配合availablePermits()可以随时看桶里还剩多少令牌方便上线后观察真实水位// 全局限速所有网关实例合计 500 许可/秒 limiter.setRate(RateType.OVERALL, 500, 1, RateIntervalUnit.SECONDS); // 实时余量接到监控里 System.out.println(limiter.availablePermits());第 3 步请求进来时取许可。网关场景强烈建议用带超时的tryAcquire而不是无限阻塞的acquire——前者拿不到许可会立刻告诉你不行后者会把 Netty 工作线程吊死在等待上一次限流配置过小就能让整个网关假死// 网关过滤器里最多等 50ms拿不到立即拒绝 if (!limiter.tryAcquire(1, Duration.ofMillis(50))) { response.setStatus(429); response.setHeader(Retry-After, 1); return; // 不打后端 } // 拿到许可放行到订单服务第 4 步拒绝响应。如上429 Retry-After就是给客户端的稍后再试契约。为什么必须带Retry-After因为秒杀客户端通常会重试没有这个头它们就会以固定间隔盲打反而制造出第二个洪峰。限流策略选型全局 vs 客户端什么场景用什么RateType只有两个值但配合键名策略可以覆盖绝大多数场景。下表是选型速查需求选法为什么这么选秒杀总量保护保 DBRateType.OVERALL一个键所有实例共享一个桶集群总吞吐有上限每个网关实例各自限额RateType.PER_CLIENT桶按 Redisson 实例 ID 拆分适合每实例均摊额度的公平分摊按 IP / API Key 逐个限爬虫键名拼实体getRateLimiter(limiter:ip: ip)每个实体一个桶务必配keepAliveTime否则几万个 IP 键会永久留在 Redis 里大促临时提速updateRate(RateLimiterArgs.of(...).keepState(true))保留已用额度调整期间不会瞬间泄洪setRate会重置桶状态慎用网关要快速失败tryAcquire(permits, timeout)超时返回 false直接 429不占用线程离线批处理、任务队列acquire(n)或acquire(n, timeout)阻塞直到拿到 n 个许可适合批量消费场景不想阻塞任何线程tryAcquireAsync/ Reactive / Rx 接口Redisson 的限流器有异步、响应式、RxJava 三套同构 API两个补充说明为什么updateRate(...).keepState(true)是动态调速的正确姿势普通setRate在改速率的同时会清空已用额度等价于把桶清空重满一次大促中途提速会瞬间放过一大波积压请求。keepState(true)则按新速率重新折算剩余额度过渡是平滑的。为什么按 IP 限流用键名而不是 PER_CLIENTPER_CLIENT的粒度是每个 Redisson 实例而爬虫防护要的是每个来源 IP。把实体拼进键名是最直接的做法再给trySetRate配一个keepAliveTime如 10 分钟静默的 IP 桶会自动过期删除。常见误区限流不解决什么上线前把这四条贴到团队文档里trySetRate只在首次成功。已配置过再调用会返回 false 且不覆盖。初始化代码里用它没问题但想要每次发布都刷新配置就别指望它——该用updateRate。setRate会重置桶状态。网关启动脚本里每实例都调一次setRate每次发布等于全体限流器清零重启发布瞬间限流失效。启动逻辑里要么只trySetRate一次要么用keepState(true)的更新方式。一次请求的许可数不能超过速率本身。脚本内部有硬性校验批量任务里acquire(1000)而速率是 500/s直接抛异常。限流不保证公平。同一时刻竞争许可的请求按脚本执行先后拿到额度官方文档明确说明不做公平性保证。对顺序敏感的入口如扣减库存前置排队前面应该再挂一层队列或排队机制。更要认清边界限流只管入口速度不管内部健康。请求放进来之后后端照样可能挂——DB 变慢、依赖超时、消息积压这些要靠熔断、降级和隔离来兜底。三者分工可以这么记限流削掉入口洪峰保护容量本文做的事熔断依赖持续失败时快速失败防止线程被拖死降级熔断后返回兜底数据或简化功能保住核心链路。只做限流不做熔断等于只堵了正门侧门慢依赖照样漏。收束把 Redisson 分布式限流接进 API 网关核心就四件事给每个需要保护的接口起一个独立的限流器键、按后端真实容量设 OVERALL 速率、过滤器里用带超时的 tryAcquire 快速失败、拒绝时回 429 加 Retry-After再配上 updateRate 做平滑调速、keepAliveTime 做自动清理就能覆盖秒杀、爬虫这两类最常见的洪峰。它和熔断、降级各守一段组合起来才是完整的网关防护。更多细节见官方文档 docs/data-and-services/objects.md 中的 RateLimiter 章节项目全貌可以看 docs/overview.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),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价