架构思维： 高并发场景下的系统限流实战

Pre

架构思维：重温限流算法原理与实战

引言

在当今互联网应用中，高并发已成为常态。当系统面临流量洪峰时，如果没有有效的保护机制，很容易导致服务雪崩。作为系统架构师和开发者，我们不仅要考虑如何提升系统性能，更要思考如何在流量超过系统承载能力时进行有效保护。限流作为服务降级的重要手段，在分布式高可用设计中扮演着关键角色。

本文将深入探讨高并发场景下的系统限流技术，从理论原理到代码实现，构建可靠的流量防护体系。

• 限流的核心概念与应用场景
• 三种主流限流算法的原理与实现
• 分布式环境下的限流实践
• 实际项目中的限流策略设计

一、为什么需要限流？

在分布式系统中，服务之间的调用形成了复杂的依赖网络。当某个服务的流量突然激增时，如果没有限流保护，可能会产生连锁反应，导致整个系统崩溃。

限流的核心价值：

• 防止系统过载，保护核心服务稳定性
• 避免资源耗尽（如线程池、数据库连接等）
• 控制成本，防止异常流量导致资源浪费
• 为系统提供"缓冲期"，应对突发流量

限流的典型场景：

• 秒杀/抢购活动
• 爬虫防护
• API服务调用保护
• 第三方服务调用保护
• 金融交易系统

二、限流算法详解与实现

2.1 计数器法

原理

计数器法是最简单的限流算法，通过统计单位时间内的请求数来实现限流。例如：限制1秒内最多100次请求，超过则拒绝。

优缺点

• 优点：实现简单，适合集群环境
• 缺点：存在临界问题（窗口切换时可能出现2倍流量）

实现

import java.util.concurrent.atomic.AtomicInteger;

/**
 * 计数器限流实现
 * 环境要求：JDK 8+
 */
public class CounterLimiter {
    // 初始时间
    private static long startTime = System.currentTimeMillis();
    // 时间窗口大小（毫秒）
    private final int windowSize;
    // 限流阈值
    private final int limit;
    // 请求计数器
    private final AtomicInteger requestCount;
    
    /**
     * 构造函数
     * @param windowSize 时间窗口大小（毫秒）
     * @param limit 限流阈值
     */
    public CounterLimiter(int windowSize, int limit) {
        this.windowSize = windowSize;
        this.limit = limit;
        this.requestCount = new AtomicInteger(0);
    }
    
    /**
     * 尝试获取许可
     * @return true-允许通过，false-拒绝
     */
    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        
        // 检查是否在时间窗口内
        if (now < startTime + windowSize) {
            // 检查是否超过限流阈值
            if (requestCount.get() < limit) {
                requestCount.incrementAndGet();
                return true;
            }
            return false;
        } else {
            // 时间窗口重置
            startTime = now;
            requestCount.set(0);
            return true;
        }
    }
    
    /**
     * 获取当前计数
     * @return 当前窗口内的请求数
     */
    public int getCurrentCount() {
        return requestCount.get();
    }
    
    /**
     * 获取剩余可用请求数
     * @return 剩余可用请求数
     */
    public int getRemaining() {
        return Math.max(0, limit - requestCount.get());
    }
    
    /**
     * 演示用例
     */
    public static void main(String[] args) throws InterruptedException {
        // 限制1秒内最多100次请求
        CounterLimiter limiter = new CounterLimiter(1000, 100);
        
        // 模拟高并发请求
        for (int i = 0; i < 150; i++) {
            new Thread(() -> {
                if (limiter.tryAcquire()) {
                    System.out.println("请求成功，当前计数：" + limiter.getCurrentCount());
                } else {
                    System.out.println("请求被限流");
                }
            }).start();
            Thread.sleep(5); // 模拟请求间隔
        }
        
        // 等待所有线程执行完成
        Thread.sleep(2000);
        System.out.println("1秒后重置，当前计数：" + limiter.getCurrentCount());
    }
}

集群环境实现

在分布式环境中，可以使用Redis实现集群计数器限流：

import redis.clients.jedis.Jedis;

/**
 * Redis计数器限流实现
 * 依赖：Jedis 3.0+
 */
public class RedisCounterLimiter {
    private final Jedis jedis;
    private final String key;
    private final int windowSize; // 毫秒
    private final int limit;
    
    public RedisCounterLimiter(Jedis jedis, String key, int windowSize, int limit) {
        this.jedis = jedis;
        this.key = key;
        this.windowSize = windowSize;
        this.limit = limit;
    }
    
    public boolean tryAcquire() {
        // 使用Redis的INCR命令原子性增加计数
        Long count = jedis.incr(key);
        
        if (count == 1) {
            // 首次请求，设置过期时间
            jedis.pexpire(key, windowSize);
        }
        
        return count <= limit;
    }
    
    /**
     * 获取当前计数
     */
    public long getCurrentCount() {
        String countStr = jedis.get(key);
        return countStr != null ? Long.parseLong(countStr) : 0;
    }
}

2.2 漏桶算法

原理

漏桶算法将请求视为流入桶中的水，桶以固定速率"漏水"（处理请求）。当桶满时，新请求会被拒绝。漏桶算法能够平滑流量，但对突发流量支持不好。

优缺点

• 优点：流量平滑，不会出现突发流量
• 缺点：无法应对突发流量，资源利用率不高

实现

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * 漏桶限流实现
 * 环境要求：JDK 8+
 */
public class LeakyBucketLimiter {
    // 桶的容量
    private final int capacity;
    // 漏水速率（每毫秒处理的请求数）
    private final double leakRate;
    // 桶中当前水量
    private double water;
    // 上次漏水时间
    private long lastLeakTime;
    // 锁，保证线程安全
    private final Lock lock = new ReentrantLock();
    
    /**
     * 构造函数
     * @param capacity 桶的容量
     * @param leakRate 漏水速率（每秒处理的请求数）
     */
    public LeakyBucketLimiter(int capacity, double leakRate) {
        this.capacity = capacity;
        this.leakRate = leakRate / 1000.0; // 转换为每毫秒处理速率
        this.water = 0;
        this.lastLeakTime = System.currentTimeMillis();
    }
    
    /**
     * 尝试获取许可
     * @return true-允许通过，false-拒绝
     */
    public boolean tryAcquire() {
        lock.lock();
        try {
            // 先执行漏水操作
            long now = System.currentTimeMillis();
            long elapsedTime = now - lastLeakTime;
            double leakedWater = elapsedTime * leakRate;
            water = Math.max(0, water - leakedWater);
            lastLeakTime = now;
            
            // 检查是否可以加入新请求
            if (water < capacity) {
                water++;
                return true;
            }
            return false;
        } finally {
            lock.unlock();
        }
    }
    
    /**
     * 获取当前桶中水量
     */
    public double getCurrentWater() {
        lock.lock();
        try {
            long now = System.currentTimeMillis();
            long elapsedTime = now - lastLeakTime;
            double leakedWater = elapsedTime * leakRate;
            return Math.max(0, water - leakedWater);
        } finally {
            lock.unlock();
        }
    }
    
    /**
     * 演示用例
     */
    public static void main(String[] args) throws InterruptedException {
        // 桶容量100，每秒处理50个请求
        LeakyBucketLimiter limiter = new LeakyBucketLimiter(100, 50);
        
        // 模拟突发流量
        for (int i = 0; i < 150; i++) {
            if (limiter.tryAcquire()) {
                System.out.println("请求成功，当前水量：" + limiter.getCurrentWater());
            } else {
                System.out.println("请求被限流");
            }
            // 模拟快速请求
            if (i < 10) Thread.sleep(10);
        }
        
        // 等待一段时间，让桶中的水漏掉一些
        Thread.sleep(1000);
        System.out.println("1秒后，当前水量：" + limiter.getCurrentWater());
        
        // 继续发送请求
        for (int i = 0; i < 50; i++) {
            if (limiter.tryAcquire()) {
                System.out.println("请求成功，当前水量：" + limiter.getCurrentWater());
            } else {
                System.out.println("请求被限流");
            }
            Thread.sleep(20);
        }
    }
}

2.3 令牌桶算法

原理

令牌桶算法以固定速率向桶中添加令牌，请求需要获取令牌才能执行。桶有最大容量，当桶满时，新令牌会被丢弃。相比漏桶算法，令牌桶允许一定程度的突发流量。

优缺点

• 优点：支持突发流量，资源利用率高
• 缺点：实现相对复杂

Guava RateLimiter实现

Google Guava库提供了简单易用的令牌桶实现：

import com.google.common.util.concurrent.RateLimiter;

/**
 * Guava RateLimiter演示
 * 依赖：Guava 20.0+
 */
public class GuavaRateLimiterDemo {
    
    public static void main(String[] args) {
        // 创建一个每秒允许5个请求的限流器
        RateLimiter limiter = RateLimiter.create(5.0);
        
        System.out.println("开始测试突发流量处理能力...");
        
        // 模拟突发流量
        for (int i = 0; i < 10; i++) {
            // 获取1个令牌
            double waitTime = limiter.acquire(1);
            System.out.printf("第%d次请求，等待%.2f秒%n", i + 1, waitTime);
        }
        
        System.out.println("\n测试非阻塞获取令牌...");
        
        // 测试非阻塞获取
        for (int i = 0; i < 10; i++) {
            boolean allowed = limiter.tryAcquire(1);
            System.out.println("第" + (i + 1) + "次请求" + (allowed ? "成功" : "被拒绝"));
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
        
        System.out.println("\n测试批量获取令牌...");
        
        // 测试批量获取
        for (int i = 0; i < 5; i++) {
            double waitTime = limiter.acquire(3);
            System.out.printf("批量获取3个令牌，等待%.2f秒%n", waitTime);
        }
    }
}

手动实现令牌桶算法

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 * 令牌桶限流实现
 * 环境要求：JDK 8+
 */
public class TokenBucketLimiter {
    // 桶的容量
    private final int capacity;
    // 令牌生成速率（每毫秒生成的令牌数）
    private final double tokenRate;
    // 当前桶中令牌数
    private double tokens;
    // 上次填充令牌的时间
    private long lastFillTime;
    // 锁，保证线程安全
    private final Lock lock = new ReentrantLock();
    
    /**
     * 构造函数
     * @param capacity 桶的容量
     * @param tokenRate 令牌生成速率（每秒生成的令牌数）
     */
    public TokenBucketLimiter(int capacity, double tokenRate) {
        this.capacity = capacity;
        this.tokenRate = tokenRate / 1000.0; // 转换为每毫秒生成速率
        this.tokens = capacity; // 初始化时桶是满的
        this.lastFillTime = System.currentTimeMillis();
    }
    
    /**
     * 尝试获取指定数量的令牌
     * @param tokenCount 请求的令牌数量
     * @return true-获取成功，false-获取失败
     */
    public boolean tryAcquire(int tokenCount) {
        if (tokenCount <= 0) {
            throw new IllegalArgumentException("tokenCount must be positive");
        }
        
        lock.lock();
        try {
            // 填充令牌
            refillTokens();
            
            // 检查是否有足够的令牌
            if (tokens >= tokenCount) {
                tokens -= tokenCount;
                return true;
            }
            return false;
        } finally {
            lock.unlock();
        }
    }
    
    /**
     * 阻塞获取指定数量的令牌
     * @param tokenCount 请求的令牌数量
     * @return 等待时间（毫秒）
     */
    public long acquire(int tokenCount) {
        if (tokenCount <= 0) {
            throw new IllegalArgumentException("tokenCount must be positive");
        }
        
        lock.lock();
        try {
            // 填充令牌
            refillTokens();
            
            // 如果没有足够的令牌，计算需要等待的时间
            if (tokens < tokenCount) {
                double deficit = tokenCount - tokens;
                long waitTime = (long) (deficit / tokenRate);
                // 等待直到有足够的令牌
                try {
                    Thread.sleep(waitTime);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
                // 重新填充令牌（因为等待期间可能生成了新令牌）
                refillTokens();
            }
            
            // 获取令牌
            tokens -= tokenCount;
            return Math.max(0, (long) (tokenCount / tokenRate));
        } finally {
            lock.unlock();
        }
    }
    
    /**
     * 填充令牌
     */
    private void refillTokens() {
        long now = System.currentTimeMillis();
        long elapsedTime = now - lastFillTime;
        
        // 计算新生成的令牌数
        double newTokens = elapsedTime * tokenRate;
        tokens = Math.min(capacity, tokens + newTokens);
        lastFillTime = now;
    }
    
    /**
     * 获取当前令牌数
     */
    public double getCurrentTokens() {
        lock.lock();
        try {
            refillTokens();
            return tokens;
        } finally {
            lock.unlock();
        }
    }
    
    /**
     * 演示用例
     */
    public static void main(String[] args) throws InterruptedException {
        // 桶容量100，每秒生成50个令牌
        TokenBucketLimiter limiter = new TokenBucketLimiter(100, 50);
        
        System.out.println("测试突发流量处理能力...");
        
        // 模拟突发流量
        for (int i = 0; i < 120; i++) {
            if (limiter.tryAcquire(1)) {
                System.out.println("请求成功，当前令牌数：" + limiter.getCurrentTokens());
            } else {
                System.out.println("请求被限流，当前令牌数：" + limiter.getCurrentTokens());
            }
            // 模拟快速请求
            if (i < 10) Thread.sleep(10);
        }
        
        System.out.println("\n测试阻塞获取...");
        
        // 测试阻塞获取
        for (int i = 0; i < 10; i++) {
            long waitTime = limiter.acquire(10);
            System.out.printf("获取10个令牌，等待%.2f秒，当前令牌数：%.2f%n", 
                    waitTime / 1000.0, limiter.getCurrentTokens());
        }
    }
}

三、限流算法对比与选型建议

选型建议

1. 对突发流量敏感的场景：选择令牌桶算法

   • 例如：电商秒杀、抢购活动
   • 理由：允许一定程度的突发流量，提高用户体验

2. 需要严格控制流量的场景：选择漏桶算法

   • 例如：API网关的流量控制
   • 理由：提供稳定的流量输出，避免后端服务过载

3. 简单快速实现限流：选择计数器法

   • 例如：小型应用或临时保护措施
   • 理由：实现简单，适合快速上线

4. 分布式系统：结合Redis实现分布式限流

   • 例如：微服务架构中的服务保护
   • 理由：保证集群整体的流量控制

四、分布式环境下的限流实践

在分布式系统中，单机限流往往不够，需要考虑集群级别的限流策略。

4.1 Redis+Lua分布式限流

Redis提供了原子操作，结合Lua脚本可以实现高效的分布式限流：

import redis.clients.jedis.Jedis;
import redis.clients.jedis.params.SetParams;

/**
 * Redis+Lua分布式令牌桶限流
 * 依赖：Jedis 3.0+
 */
public class RedisTokenBucketLimiter {
    private final Jedis jedis;
    private final String key;
    private final int capacity;
    private final double refillRate; // 每秒生成的令牌数
    
    // 令牌桶Lua脚本
    private static final String LUA_SCRIPT = 
        "local tokens = redis.call('HGET', KEYS[1], 'tokens')\n" +
        "local timestamp = redis.call('HGET', KEYS[1], 'timestamp')\n" +
        "local now = tonumber(ARGV[1])\n" +
        "local capacity = tonumber(ARGV[2])\n" +
        "local refillRate = tonumber(ARGV[3])\n" +
        "\n" +
        "if not tokens then\n" +
        "  tokens = capacity\n" +
        "  timestamp = now\n" +
        "end\n" +
        "\n" +
        "local elapsedTime = now - tonumber(timestamp)\n" +
        "local filledTokens = math.min(capacity, tonumber(tokens) + elapsedTime * refillRate)\n" +
        "local allowed = filledTokens >= tonumber(ARGV[4])\n" +
        "local newTokens = allowed and (filledTokens - tonumber(ARGV[4])) or filledTokens\n" +
        "\n" +
        "if allowed then\n" +
        "  redis.call('HMSET', KEYS[1], 'tokens', newTokens, 'timestamp', now)\n" +
        "  redis.call('EXPIRE', KEYS[1], 2 * capacity / refillRate)\n" +
        "end\n" +
        "\n" +
        "return allowed and 1 or 0";
    
    public RedisTokenBucketLimiter(Jedis jedis, String key, int capacity, double refillRate) {
        this.jedis = jedis;
        this.key = key;
        this.capacity = capacity;
        this.refillRate = refillRate;
    }
    
    public boolean tryAcquire(int tokenCount) {
        long now = System.currentTimeMillis();
        Object result = jedis.eval(
            LUA_SCRIPT,
            1,
            key,
            String.valueOf(now),
            String.valueOf(capacity),
            String.valueOf(refillRate),
            String.valueOf(tokenCount)
        );
        return ((Long) result) == 1L;
    }
    
    /**
     * 获取当前令牌数（仅用于监控）
     */
    public double getCurrentTokens() {
        String tokensStr = jedis.hget(key, "tokens");
        if (tokensStr == null) {
            return capacity;
        }
        return Double.parseDouble(tokensStr);
    }
}

4.2 Spring Cloud Gateway限流实践

在微服务架构中，可以在网关层实现统一的限流策略：

import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver;
import org.springframework.cloud.gateway.filter.ratelimit.RedisRateLimiter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import reactor.core.publisher.Mono;

/**
 * Spring Cloud Gateway限流配置
 * 依赖：Spring Cloud Gateway 2020.0.3+
 */
@Configuration
public class GatewayRateLimitConfig {

    /**
     * 基于用户ID的限流Key解析器
     */
    @Bean
    public KeyResolver userKeyResolver() {
        return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("userId"));
    }

    /**
     * 基于IP地址的限流Key解析器
     */
    @Bean
    public KeyResolver ipKeyResolver() {
        return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getAddress().getHostAddress());
    }

    /**
     * 配置Redis限流规则
     * application.yml中配置：
     * spring:
     *   cloud:
     *     gateway:
     *       routes:
     *       - id: service-route
     *         uri: lb://service
     *         predicates:
     *         - Path=/api/**
     *         filters:
     *         - name: RequestRateLimiter
     *           args:
     *             redis-rate-limiter.replenishRate: 10 # 每秒生成10个令牌
     *             redis-rate-limiter.burstCapacity: 20 # 桶容量20
     *             key-resolver: "#{@ipKeyResolver}"
     */
    @Bean
    public RedisRateLimiter redisRateLimiter() {
        return new RedisRateLimiter(10, 20); // 默认配置
    }
}

五、实战案例：系统限流设计

让我们通过一个电商秒杀系统的实例，了解如何在实际项目中应用限流技术。

5.1 系统架构与挑战

• 场景：1000件商品，每件1元，100万人同时抢购
• 挑战：
  • 瞬时流量极高（可能达到10万QPS）
  • 需要防止恶意刷单
  • 需要保证公平性
  • 需要保护后端服务不被压垮

5.2 限流策略设计

第一层：接入层限流（Nginx）

http {
    # 限制每个IP每秒最多10个请求
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    
    server {
        location /seckill {
            # 应用限流规则
            limit_req zone=perip burst=20 nodelay;
            
            # 转发到后端服务
            proxy_pass http://backend;
        }
    }
}

第二层：网关层限流（Spring Cloud Gateway）

spring:
  cloud:
    gateway:
      routes:
      - id: seckill-service
        uri: lb://seckill-service
        predicates:
        - Path=/seckill/**
        filters:
        - name: RequestRateLimiter
          args:
            redis-rate-limiter.replenishRate: 500   # 每秒500个请求
            redis-rate-limiter.burstCapacity: 1000  # 桶容量1000
            key-resolver: "#{@userKeyResolver}"     # 基于用户ID限流

第三层：服务层限流（Guava RateLimiter）

import com.google.common.util.concurrent.RateLimiter;
import org.springframework.stereotype.Service;

@Service
public class SeckillService {
    // 全局限流器，每秒最多处理1000个请求
    private final RateLimiter globalLimiter = RateLimiter.create(1000.0);
    
    // 用户级限流器，每秒最多处理5个请求
    private final LoadingCache<String, RateLimiter> userLimiters = 
        CacheBuilder.newBuilder()
            .expireAfterAccess(10, TimeUnit.MINUTES)
            .build(new CacheLoader<String, RateLimiter>() {
                @Override
                public RateLimiter load(String userId) {
                    return RateLimiter.create(5.0);
                }
            });
    
    public boolean trySeckill(String userId, String itemId) {
        // 全局限流
        if (!globalLimiter.tryAcquire()) {
            throw new RuntimeException("系统繁忙，请稍后再试");
        }
        
        // 用户级限流
        RateLimiter userLimiter = userLimiters.getUnchecked(userId);
        if (!userLimiter.tryAcquire()) {
            throw new RuntimeException("操作过于频繁，请稍后再试");
        }
        
        // 业务逻辑...
        // 1. 检查库存
        // 2. 创建订单
        // 3. 扣减库存
        
        return true;
    }
}

第四层：资源级限流（数据库连接池）

spring:
  datasource:
    hikari:
      maximum-pool-size: 50  # 数据库连接池最大50
      connection-timeout: 3000 # 连接超时3秒

5.3 降级策略设计

当流量超过系统承载能力时，需要有合理的降级策略：

import org.springframework.stereotype.Service;
import com.netflix.hystrix.HystrixCommand;
import com.netflix.hystrix.HystrixCommandGroupKey;
import com.netflix.hystrix.HystrixCommandProperties;

@Service
public class SeckillServiceWithFallback {
    
    public boolean trySeckill(String userId, String itemId) {
        return new SeckillCommand(userId, itemId).execute();
    }
    
    private class SeckillCommand extends HystrixCommand<Boolean> {
        private final String userId;
        private final String itemId;
        
        protected SeckillCommand(String userId, String itemId) {
            super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("Seckill"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                    .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)
                    .withCircuitBreakerRequestVolumeThreshold(20) // 10秒内20次请求触发熔断
                    .withCircuitBreakerErrorThresholdPercentage(50) // 错误率50%触发熔断
                    .withCircuitBreakerSleepWindowInMilliseconds(5000) // 熔断5秒后尝试恢复
                ));
            this.userId = userId;
            this.itemId = itemId;
        }
        
        @Override
        protected Boolean run() {
            // 业务逻辑...
            return true;
        }
        
        @Override
        protected Boolean getFallback() {
            // 降级逻辑
            System.out.println("系统繁忙，已启用降级策略");
            // 1. 将请求放入消息队列异步处理
            // 2. 返回友好提示
            // 3. 记录日志用于后续分析
            return false;
        }
    }
}

六、限流实施最佳实践

6.1 容量规划与压测

在实施限流前，必须进行容量规划和压力测试：

1. 确定系统容量：

   • 通过压测确定系统最大承载能力
   • 识别系统瓶颈（CPU、内存、IO等）
   • 计算安全阈值（建议设置为最大承载能力的70-80%）

2. 设计合理的限流阈值：

   • 基于业务重要性设置不同优先级的限流策略
   • 考虑流量的季节性波动
   • 为关键业务预留足够的资源

6.2 限流监控与告警

实施限流后，必须建立完善的监控体系：

1. 关键指标监控：

   • 限流触发率
   • 被拒绝的请求数
   • 系统负载指标
   • 业务指标（订单量、转化率等）

2. 告警策略：

   • 限流触发率超过阈值时告警
   • 系统负载异常升高时告警
   • 业务指标异常波动时告警

6.3 渐进式限流策略

避免一次性设置过严格的限流阈值，建议采用渐进式策略：

1. 初始阶段：设置较为宽松的阈值，观察系统表现
2. 优化阶段：根据监控数据逐步调整阈值
3. 稳定阶段：确定最优阈值，并设置自动调整机制

6.4 限流与降级的结合

限流只是保护系统的第一步，还需要结合降级策略：

1. 延迟处理：将非关键请求放入队列异步处理
2. 拒绝服务：返回友好提示，避免系统过载
3. 降级服务：提供简化版服务，保证核心功能可用
4. 熔断机制：当依赖服务不可用时，快速失败

七、常见问题与解决方案

问题1：限流后用户体验下降

现象：用户频繁收到"系统繁忙"提示

解决方案：

• 实施分级限流策略，优先保障核心用户
• 优化限流算法，允许一定程度的突发流量
• 提供友好的等待界面，降低用户焦虑
• 实施排队机制，告知用户预计等待时间

问题2：分布式限流性能瓶颈

现象：Redis成为性能瓶颈

解决方案：

• 采用分片策略，分散Redis压力
• 使用本地缓存+Redis二级缓存
• 优化Lua脚本，减少网络往返
• 适当放宽限流精度，降低Redis调用频率

问题3：限流阈值设置不合理

现象：系统经常过载或资源利用率低

解决方案：

• 基于历史数据和业务增长趋势动态调整阈值
• 实施自适应限流，根据系统负载自动调整阈值
• 结合业务场景设置不同时间段的阈值
• 建立A/B测试机制，验证不同阈值的效果

总结

限流是构建高可用系统的重要技术手段。

记住，限流不是目的，而是保护系统稳定性的手段。合理的限流策略应该：

• 基于充分的容量规划和压测
• 结合业务特点和用户需求
• 与降级、熔断等机制协同工作
• 具备监控和动态调整能力

在实际应用中，建议从简单的计数器法开始，逐步过渡到更复杂的令牌桶算法，并根据业务需求调整限流策略。同时，要建立完善的监控体系，确保限流策略既能保护系统，又不会过度影响用户体验。

最后提醒：限流策略需要随着业务发展不断优化，没有一劳永逸的解决方案。定期回顾和调整限流策略，是保证系统长期稳定运行的关键。

扩展阅读

1. Guava RateLimiter源码分析
2. Redis分布式限流最佳实践
3. Spring Cloud Gateway限流文档
4. Hystrix熔断器模式详解