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

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解析器*/@Beanpublic KeyResolver userKeyResolver() {return exchange -> Mono.just(exchange.getRequest().getQueryParams().getFirst("userId"));}/*** 基于IP地址的限流Key解析器*/@Beanpublic 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}"*/@Beanpublic 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-serviceuri: lb://seckill-servicepredicates:- Path=/seckill/**filters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 500   # 每秒500个请求redis-rate-limiter.burstCapacity: 1000  # 桶容量1000key-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>() {@Overridepublic 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  # 数据库连接池最大50connection-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;}@Overrideprotected Boolean run() {// 业务逻辑...return true;}@Overrideprotected 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熔断器模式详解