做高并发系统的同学肯定都遇到过这个问题：设置了一个固定的限流阈值，结果流量高峰期把正常用户给限流了，导致用户投诉；或者阈值设得太高，遇到流量突增又挡不住，系统直接被打垮。 我之前就遇到过这样一个案例：我们为某个接口设置了每秒 1000 的限流阈值。结果某天下午 3 点突然来了一波流量，峰值达到 2000 QPS，系统瞬间被压垮。后来调整到 3000，结果平时大部分时间阈值都用不满，浪费了系统资源。 今天我们就来聊聊动态自适应限流的正确姿势，让限流策略能根据实际情况自动调整。 传统限流的致命缺陷 1. 固定阈值的问题 很多系统使用固定的限流阈值，比如： // 固定限流：每秒最多 1000 个请求 @RateLimiter(maxRequests = 1000, timeWindow = 1) public void processRequest() { // 业务逻辑 } 这种方式的问题很明显： 高峰期：阈值太低，误杀正常用户 低峰期：阈值太高，浪费系统资源 无法应对突发流量：固定阈值无法快速响应流量变化 2. 常见限流算法的局限性 ┌───────────────────────....

一、限流阈值设置的痛点 上个月，我在为一个电商系统做性能优化时，遇到了一个非常棘手的问题： "我们的系统在高峰期经常出现限流误杀，而在低峰期又限流不足，"技术总监皱着眉头说，"固定的限流阈值根本无法适应业务的动态变化，我们需要一个智能的方案来自动调整限流阈值。" 我查看了他们的限流配置，发现问题确实很严重： 系统使用固定的限流阈值，无法适应流量的动态变化 高峰期阈值设置过低，导致正常请求被误杀 低峰期阈值设置过高，无法有效保护系统 无法根据历史流量数据进行智能调优 没有自动推荐合理的限流阈值的机制 限流策略缺乏灵活性和适应性 更关键的是，他们根本不知道如何设置一个合理的限流阈值，只能依靠经验和猜测。 二、传统方案的局限性 1. 固定阈值限流 使用固定的限流阈值，无论流量如何变化，都使用相同的限制。 // 固定阈值限流 @Bean public RateLimiter rateLimiter() { return RateLimiter.create(100); // 固定100 QPS } 这种方案的问题： 无法适应流量变化：无法根据流量的动态变化调整阈值 高峰期误杀：高峰期阈....