一、突发流量下的动态限流策略

在电商大促、热点事件等场景中，系统常面临瞬时流量激增的挑战。若未及时控制请求量，可能导致后端服务过载、数据库连接池耗尽等连锁故障。

1.1 令牌桶算法实现

令牌桶算法通过控制令牌生成速率与桶容量，实现平滑限流。其核心逻辑为：

以固定速率向桶中添加令牌
请求到达时需从桶中获取令牌
桶中无令牌时触发限流

public class TokenBucketRateLimiter {
    private final AtomicLong tokens;
    private final long capacity;
    private final long refillTokens;
    private final long refillIntervalMillis;
    private volatile long lastRefillTime;
    public TokenBucketRateLimiter(long capacity, long refillTokens, long refillIntervalMillis) {
        this.capacity = capacity;
        this.refillTokens = refillTokens;
        this.refillIntervalMillis = refillIntervalMillis;
        this.tokens = new AtomicLong(capacity);
        this.lastRefillTime = System.currentTimeMillis();
    }
    public boolean tryAcquire() {
        refill();
        long currentTokens = tokens.get();
        if (currentTokens <= 0) return false;
        return tokens.compareAndSet(currentTokens, currentTokens - 1);
    }
    private void refill() {
        long now = System.currentTimeMillis();
        long elapsed = now - lastRefillTime;
        if (elapsed > refillIntervalMillis) {
            long newTokens = elapsed / refillIntervalMillis * refillTokens;
            tokens.updateAndGet(current -> Math.min(capacity, current + newTokens));
            lastRefillTime = now;
        }
    }
}

1.2 分布式环境下的实现方案

在微服务架构中，需采用分布式限流组件（如Redis+Lua实现）保证集群一致性。典型实现步骤：

使用Redis的INCR命令原子性增加计数器
设置计数器过期时间模拟滑动窗口
通过Lua脚本保证原子操作

-- Redis Lua脚本示例
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = redis.call("GET", key)
if current and tonumber(current) > limit then
    return 0
else
    redis.call("INCR", key)
    if tonumber(redis.call("TTL", key)) == -1 then
        redis.call("EXPIRE", key, window)
    end
    return 1
end

二、依赖服务不可用时的熔断降级

当下游服务出现延迟或故障时，及时熔断可防止故障扩散。熔断器模式包含三个状态：

Closed：正常请求，统计错误率
Open：直接拒绝请求，触发快速失败
Half-Open：试探性恢复部分流量

2.1 熔断策略实现

public class CircuitBreaker {
    private enum State { CLOSED, OPEN, HALF_OPEN }
    private final AtomicReference<State> state = new AtomicReference<>(State.CLOSED);
    private final AtomicLong failureCount = new AtomicLong(0);
    private final long failureThreshold;
    private final long resetTimeoutMillis;
    private volatile long lastFailureTime;
    public CircuitBreaker(long failureThreshold, long resetTimeoutMillis) {
        this.failureThreshold = failureThreshold;
        this.resetTimeoutMillis = resetTimeoutMillis;
    }
    public boolean allowRequest() {
        State currentState = state.get();
        switch (currentState) {
            case OPEN:
                if (System.currentTimeMillis() - lastFailureTime > resetTimeoutMillis) {
                    if (state.compareAndSet(State.OPEN, State.HALF_OPEN)) {
                        return true; // 试探性允许
                    }
                }
                return false;
            case HALF_OPEN:
                return true; // 允许部分请求
            case CLOSED:
                return true; // 正常允许
        }
        return false;
    }
    public void recordFailure() {
        if (state.get() == State.CLOSED) {
            long count = failureCount.incrementAndGet();
            if (count >= failureThreshold) {
                state.set(State.OPEN);
                lastFailureTime = System.currentTimeMillis();
                failureCount.set(0);
            }
        }
    }
}

2.2 降级策略设计

当熔断触发时，需提供降级方案保证核心功能：

静态降级：返回缓存数据或默认值
异步降级：将请求写入消息队列异步处理
主备降级：切换至备用服务或数据源

三、异步处理中的队列缓冲

对于耗时操作（如文件上传、复杂计算），可通过队列实现削峰填谷。典型架构包含：

生产者：接收请求并写入队列
消息队列：持久化存储待处理任务
消费者：多线程处理队列任务

3.1 队列参数调优

关键参数配置建议：
| 参数 | 推荐值 | 作用 |
|———————-|——————-|—————————————|
| 队列容量 | 峰值QPS×30s | 防止内存溢出 |
| 消费者线程数 | CPU核心数×2 | 平衡吞吐与资源占用 |
| 重试次数 | 3次 | 平衡成功率与系统负载 |

3.2 死信队列处理

对于处理失败的消息，需实现：

记录失败原因与时间戳
转移至死信队列单独处理
设置最大重试次数限制

public class QueueProcessor {
    private final BlockingQueue<Task> queue;
    private final ExecutorService executor;
    private final DeadLetterQueue deadLetterQueue;
    public QueueProcessor(int queueSize, int threadPoolSize) {
        this.queue = new LinkedBlockingQueue<>(queueSize);
        this.executor = Executors.newFixedThreadPool(threadPoolSize);
        this.deadLetterQueue = new DeadLetterQueue();
        for (int i = 0; i < threadPoolSize; i++) {
            executor.submit(this::processTasks);
        }
    }
    private void processTasks() {
        while (true) {
            try {
                Task task = queue.poll(1, TimeUnit.SECONDS);
                if (task != null) {
                    try {
                        task.execute();
                    } catch (Exception e) {
                        if (task.getRetryCount() >= MAX_RETRIES) {
                            deadLetterQueue.add(task);
                        } else {
                            task.incrementRetry();
                            queue.offer(task); // 重试
                        }
                    }
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            }
        }
    }
}

四、弹性扩容的自动化策略

对于可预测的流量增长，可通过自动化扩容实现资源弹性伸缩。典型实现方案：

4.1 基于指标的扩容规则

# 示例扩容规则配置
scalingRules:
  - metric: CPUUtilization
    threshold: 70%
    step: 2
    cooldown: 300s
  - metric: RequestPerSecond
    threshold: 5000
    step: 1
    cooldown: 60s

4.2 扩容实施流程

监控采集：实时收集CPU、内存、QPS等指标
规则评估：每30秒评估是否触发扩容条件
预热阶段：新实例启动后进行健康检查
流量切入：通过负载均衡逐步分配流量
缩容评估：持续监控资源使用率决定是否缩容

4.3 容器化环境实现

在Kubernetes环境中，可通过Horizontal Pod Autoscaler（HPA）实现：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: service-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: External
    external:
      metric:
        name: requests_per_second
        selector:
          matchLabels:
            app: service
      target:
        type: AverageValue
        averageValue: 5000

五、综合实践建议

全链路压测：在生产环境前模拟真实流量验证控制策略
灰度发布：逐步扩大流量观察系统表现
监控告警：设置关键指标的阈值告警
故障演练：定期进行混沌工程实验验证容错能力

通过合理组合上述四种策略，可构建适应不同并发场景的控制体系。实际实施时需根据业务特点、成本预算和技术栈选择最适合的方案组合，并通过持续优化实现系统稳定性与资源利用率的平衡。

高并发场景下的数量控制策略：四大场景与解决方案