引言

在高并发的互联网应用中，系统保护是一个永恒的话题。传统的限流策略往往是静态的，一旦设定就很难根据系统实时状况进行调整。但现实中，系统负载是动态变化的，我们需要一种更智能的限流方案。

今天，我要分享一套SpringBoot自适应限流与系统负载联动的完整解决方案，当CPU使用率升高时，系统会自动降低非核心接口的流量限制，确保核心接口的可用性，真正实现"保主链路"的目标。

问题背景

传统限流的痛点

想象这样一个电商系统：

• 用户访问商品详情页（核心接口）
• 同时也在浏览推荐商品（非核心接口）
• 突然出现流量高峰，CPU使用率飙升至90%以上
• 所有接口都按同样的限流规则处理
• 结果：核心业务受到影响，用户体验下降

业务场景分析

在实际业务中，接口通常有不同的重要性：

• 核心接口：订单查询、支付接口、用户登录等
• 非核心接口：推荐服务、统计接口、日志上报等

当系统压力过大时，我们应该优先保障核心接口的可用性，而非核心接口可以适当降级。

解决方案设计

核心架构思路

我设计了一套三层防护体系：

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   系统负载监控  │───▶│  自适应限流器  │───▶│  请求处理      │
│   (CPU/内存等)  │    │  (动态调整)    │    │  (降级/放行)   │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         ▼                       ▼                       ▼
   实时采集指标        根据负载调整限流参数      核心/非核心接口分流

关键技术选型

为什么选择JMX进行系统监控？

• 直接集成在JVM中，无需额外依赖
• 提供丰富的系统指标
• 性能开销小

为什么使用Redis实现分布式限流？

• 高性能的原子操作
• 支持Lua脚本，保证操作原子性
• 适合分布式环境

核心实现详解

1. 系统负载监控

@Component
public class SystemLoadMonitor {
    
    private final OperatingSystemMXBean osBean = ManagementFactory.getOperatingSystemMXBean();
    
    public double getCpuUsage() {
        try {
            if (osBean instanceof com.sun.management.OperatingSystemMXBean) {
                com.sun.management.OperatingSystemMXBean sunOsBean =
                        (com.sun.management.OperatingSystemMXBean) osBean;
                return sunOsBean.getCpuLoad() * 100;
            } else {
                return osBean.getSystemCpuLoad() * 100;
            }
        } catch (Exception e) {
            log.warn("获取CPU使用率失败，使用默认值", e);
            return 0.0;
        }
    }
    
    public double getMemoryUsage() {
        try {
            Runtime runtime = Runtime.getRuntime();
            long totalMemory = runtime.totalMemory();
            long freeMemory = runtime.freeMemory();
            long usedMemory = totalMemory - freeMemory;
            return (double) usedMemory / totalMemory * 100;
        } catch (Exception e) {
            log.warn("获取内存使用率失败", e);
            return 0.0;
        }
    }
}

关键点：

• 使用JMX获取系统指标
• 对不同JVM版本做兼容处理
• 异常时提供默认值，保证系统稳定性

2. 负载级别定义

public enum LoadLevel {
    /**
     * 正常负载
     */
    NORMAL(0, "正常"),

    /**
     * 轻度负载
     */
    LIGHT(1, "轻度"),

    /**
     * 中度负载
     */
    MEDIUM(2, "中度"),

    /**
     * 重度负载
     */
    HEAVY(3, "重度");

    public static LoadLevel getByCpuUsage(double cpuUsage, int lightThreshold, 
                                         int mediumThreshold, int heavyThreshold) {
        if (cpuUsage < lightThreshold) {
            return NORMAL;
        } else if (cpuUsage < mediumThreshold) {
            return LIGHT;
        } else if (cpuUsage < heavyThreshold) {
            return MEDIUM;
        } else {
            return HEAVY;
        }
    }
}

设计思路：

• 四个负载级别，便于精细化控制
• 根据CPU使用率动态判定
• 阈值可配置，适应不同业务场景

3. 自适应限流管理器

@Component
public class AdaptiveRateLimitManager {
    
    @Autowired
    private SystemLoadMonitor systemLoadMonitor;
    
    @Autowired
    private RateLimitService rateLimitService;
    
    // 当前系统负载级别
    private volatile LoadLevel currentLoadLevel = LoadLevel.NORMAL;
    
    /**
     * 根据接口类型和当前负载级别获取动态限流参数
     */
    public int getDynamicLimit(RateLimitType type) {
        int baseLimit = properties.getDefaultQps();
        
        // 检查是否需要降级
        if (degradationStrategy.shouldDegrade(type)) {
            return degradationStrategy.getDegradedLimit(type);
        }
        
        // 根据当前负载级别调整限流参数
        switch (currentLoadLevel) {
            case NORMAL:
                return baseLimit;
            case LIGHT:
                return (int) (baseLimit * 0.9);
            case MEDIUM:
                if (type == RateLimitType.CORE) {
                    return (int) (baseLimit * properties.getCoreInterfaceRatio());
                } else {
                    return (int) (baseLimit * properties.getNonCoreInterfaceRatio());
                }
            case HEAVY:
                if (type == RateLimitType.CORE) {
                    return Math.max(properties.getMinQps(), 
                        (int) (baseLimit * properties.getCoreInterfaceRatio() * 0.8));
                } else {
                    return Math.max(properties.getMinQps(), 
                        (int) (baseLimit * properties.getNonCoreInterfaceRatio() * 0.5));
                }
            default:
                return baseLimit;
        }
    }
}

核心逻辑：

• 根据负载级别动态调整QPS限制
• 核心接口和非核心接口区别对待
• 重度负载时大幅降低非核心接口限制

4. 分布式限流实现

@Service
public class RedisRateLimitServiceImpl implements RateLimitService {
    
    private static final String SLIDING_WINDOW_SCRIPT =
            "local key = KEYS[1]\n" +
            "local current_time = tonumber(ARGV[1])\n" +
            "local window_size = tonumber(ARGV[2])\n" +
            "local max_requests = tonumber(ARGV[3])\n" +
            "\n" +
            "-- 移除窗口外的请求记录\n" +
            "redis.call('ZREMRANGEBYSCORE', key, 0, current_time - window_size)\n" +
            "\n" +
            "-- 获取当前窗口内的请求数\n" +
            "local current_requests = redis.call('ZCARD', key)\n" +
            "\n" +
            "if current_requests < max_requests then\n" +
            "    -- 添加当前请求到有序集合\n" +
            "    redis.call('ZADD', key, current_time, current_time .. ':' .. math.random(1000000))\n" +
            "    redis.call('EXPIRE', key, window_size)\n" +
            "    return 1  -- 允许请求\n" +
            "else\n" +
            "    return 0  -- 拒绝请求\n" +
            "end";
    
    private final RedisScript<Long> slidingWindowScript = 
        new DefaultRedisScript<>(SLIDING_WINDOW_SCRIPT, Long.class);
    
    @Override
    public boolean tryAcquire(String key, int permits, int timeWindow) {
        try {
            Long result = redisTemplate.execute(slidingWindowScript,
                    Collections.singletonList("rate_limit:" + key),
                    String.valueOf(System.currentTimeMillis() / 1000),
                    String.valueOf(timeWindow),
                    String.valueOf(permits)
            );
            
            return result != null && result == 1L;
        } catch (Exception e) {
            log.error("限流检查异常", e);
            // 异常时默认允许请求，避免影响正常业务
            return true;
        }
    }
}

关键技术点：

• 使用Lua脚本保证原子性
• 滑动窗口算法精确控制
• 异常容错设计

5. 声明式限流注解

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface AdaptiveRateLimit {
    String name() default "";
    RateLimitType type() default RateLimitType.CORE;  // 核心/非核心接口
    String key() default "";
    int timeWindow() default 60;
    int permits() default 100;
    String message() default "请求过于频繁，请稍后再试";
    boolean enabled() default true;
}

6. AOP切面实现

@Aspect
@Component
public class AdaptiveRateLimitAspect {
    
    @Autowired
    private AdaptiveRateLimitManager adaptiveRateLimitManager;
    
    @Around("@annotation(adaptiveRateLimit)")
    public Object around(ProceedingJoinPoint joinPoint, 
                        AdaptiveRateLimit adaptiveRateLimit) throws Throwable {
        if (!adaptiveRateLimit.enabled()) {
            return joinPoint.proceed();
        }
        
        String key = generateKey(joinPoint, adaptiveRateLimit);
        RateLimitType type = adaptiveRateLimit.type();
        int timeWindow = adaptiveRateLimit.timeWindow();
        
        // 检查是否允许请求
        boolean allowed = adaptiveRateLimitManager.isAllowed(key, type, timeWindow);
        
        if (allowed) {
            return joinPoint.proceed();
        } else {
            log.warn("请求被限流: key={}, type={}, message={}", 
                    key, type, adaptiveRateLimit.message());
            throw new RateLimitException(adaptiveRateLimit.message());
        }
    }
}

使用示例

1. 核心接口应用

@RestController
@RequestMapping("/api")
public class OrderController {
    
    @GetMapping("/order/{orderId}")
    @AdaptiveRateLimit(
        name = "order-query",
        type = RateLimitType.CORE,  // 核心接口
        key = "'order:' + #orderId",
        timeWindow = 60,
        permits = 200,  // 高QPS限制
        message = "订单查询过于频繁"
    )
    public OrderDetail getOrder(@PathVariable String orderId) {
        return orderService.getOrder(orderId);
    }
}

2. 非核心接口应用

@RestController
@RequestMapping("/api")
public class RecommendationController {
    
    @GetMapping("/recommendation/{userId}")
    @AdaptiveRateLimit(
        name = "recommendation-query",
        type = RateLimitType.NON_CORE,  // 非核心接口
        key = "'recommendation:' + #userId",
        timeWindow = 60,
        permits = 50,  // 低QPS限制
        message = "推荐服务访问过于频繁"
    )
    public List<Product> getRecommendation(@PathVariable String userId) {
        return recommendationService.getRecommendation(userId);
    }
}

3. 配置文件

# application.yml
adaptive:
  rate:
    limit:
      enabled: true
      cpu:
        threshold:
          light: 60   # 轻度负载阈值
          medium: 75  # 中度负载阈值
          heavy: 90   # 重度负载阈值
      core-interface-ratio: 0.8     # 核心接口在高负载时保留比例
      non-core-interface-ratio: 0.2 # 非核心接口在高负载时保留比例
      check-interval: 5000          # 负载检查间隔(毫秒)
      default-qps: 100              # 默认QPS限制
      min-qps: 10                   # 最小QPS限制

性能优化建议

1. 本地缓存优化

// 在限流服务中加入本地缓存，减少Redis访问
private final LoadingCache<String, Boolean> localCache = Caffeine.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(Duration.ofSeconds(1))
    .build(this::checkRateLimit);

2. 监控指标

// 添加限流相关的监控指标
MeterRegistry meterRegistry;
Counter rateLimitedCounter = Counter.builder("rate_limit_requests_total")
    .description("被限流的请求数")
    .register(meterRegistry);

3. 配置调优

spring:
  redis:
    lettuce:
      pool:
        max-active: 50    # 根据并发量调整
        max-idle: 20
        min-idle: 5

生产环境部署建议

1. 阈值设定

• 根据压测结果设定合理的CPU阈值
• 核心接口比例不宜过低，确保业务连续性
• 定期回顾和调整配置参数

2. 监控告警

// 实现限流统计和告警
@Scheduled(fixedRate = 30000) // 每30秒检查一次
public void checkRateLimitAlerts() {
    // 检查限流情况，必要时发送告警
}

3. 容灾预案

• 准备限流降级开关
• 设计人工干预机制
• 建立灰度发布流程

总结

这套自适应限流方案通过以下三个核心机制实现了CPU高负载时的智能降级：

1. 系统负载监控：实时感知系统压力
2. 差异化限流：核心与非核心接口区别对待
3. 动态调整：根据负载级别自动调整限流参数

通过这种设计，我们能够在系统压力增大时，优先保障核心业务的可用性，实现真正的"保主链路"。在实际应用中，建议根据具体业务场景调整相关参数，持续优化限流策略。

记住，限流不是目的，而是手段。最终目标是在保证系统稳定的前提下，最大化业务价值！

公众号：服务端技术精选