2. API限流核心概念：令牌桶、漏桶、计数器算法原理对比

在金融压力测试与高可用架构设计中，限流算法是保护系统不被突发流量冲垮的第一道防线。本章深入剖析三种最核心的限流算法——令牌桶、漏桶、计数器，从原理、实现到金融场景适用性进行系统性对比。

2.1 计数器算法（固定窗口）

计数器算法是最直观的限流实现，将时间划分为固定大小的窗口（如1秒），在每个窗口内维护一个计数器，请求到达时计数器加1，若计数器超过阈值则拒绝后续请求，窗口结束时计数器重置。

// 计数器算法核心实现（伪代码）
public class CounterRateLimiter {
    private final long windowSizeMs = 1000;  // 1秒窗口
    private final int maxRequests = 100;      // 窗口内最大请求数
    private long windowStart = System.currentTimeMillis();
    private int counter = 0;

    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        if (now - windowStart > windowSizeMs) {
            windowStart = now;
            counter = 0;
        }
        if (counter < maxRequests) {
            counter++;
            return true;
        }
        return false;
    }
}

2.2 漏桶算法

漏桶算法将请求视为水滴，以固定速率从桶底漏出（处理），桶容量有限，当桶满时新请求被丢弃。漏桶强制输出速率恒定，无论入口流量如何波动。

// 漏桶算法核心实现（伪代码）
public class LeakyBucket {
    private final long capacity = 100;           // 桶容量
    private final long leakRate = 10;            // 每秒漏出速率
    private long water = 0;                      // 当前水量
    private long lastLeakTime = System.currentTimeMillis();

    public synchronized boolean tryAcquire() {
        long now = System.currentTimeMillis();
        // 先漏水：根据时间差计算漏出量
        long elapsed = now - lastLeakTime;
        long leaked = (elapsed * leakRate) / 1000;
        water = Math.max(0, water - leaked);
        lastLeakTime = now;

        if (water < capacity) {
            water++;
            return true;
        }
        return false;
    }
}

2.3 令牌桶算法

令牌桶算法以固定速率向桶中放入令牌，请求到达时需从桶中获取令牌才能通过。桶有最大容量限制，允许一定程度的突发——当桶满时，可一次性取出多个令牌应对突发流量。

// 令牌桶算法核心实现（伪代码）
public class TokenBucket {
    private final long capacity = 100;           // 桶容量（最大令牌数）
    private final long refillRate = 10;          // 每秒补充令牌数
    private long tokens = capacity;              // 当前令牌数
    private long lastRefillTime = System.currentTimeMillis();

    public synchronized boolean tryAcquire(int needTokens) {
        long now = System.currentTimeMillis();
        // 先补充令牌
        long elapsed = now - lastRefillTime;
        long newTokens = (elapsed * refillRate) / 1000;
        tokens = Math.min(capacity, tokens + newTokens);
        lastRefillTime = now;

        if (tokens >= needTokens) {
            tokens -= needTokens;
            return true;
        }
        return false;
    }
}

2.4 三种算法核心对比

2.5 算法演进：从固定窗口到滑动窗口

计数器算法的“窗口临界突变”问题催生了滑动窗口算法。滑动窗口将固定窗口细分为多个小格子（如1秒窗口分为10个100ms格子），每个格子独立计数，窗口滑动时丢弃过期格子数据，使限流判断更平滑。

// 滑动窗口核心思路（伪代码）
public class SlidingWindowCounter {
    private final int windowSizeMs = 1000;
    private final int slotCount = 10;           // 10个格子
    private final int[] slots = new int[slotCount];
    private int currentSlot = 0;
    private long lastMoveTime = System.currentTimeMillis();

    public synchronized boolean tryAcquire(int threshold) {
        moveWindow();  // 滑动窗口，重置过期格子
        int total = sumAllSlots();
        if (total < threshold) {
            slots[currentSlot]++;
            return true;
        }
        return false;
    }
}

2.6 算法选择决策树

在金融系统架构设计中，选择哪种限流算法取决于业务特征与性能要求。以下决策树可辅助判断：

• 是否需要绝对平滑的输出速率？ → 是 → 漏桶（消息队列消费、数据导出）
• 是否需要应对突发流量？ → 是 → 令牌桶（交易网关、行情推送）
• 实现简单且对精度要求不高？ → 是 → 计数器（后台批处理、非核心链路）
• 需要高精度且能容忍一定复杂度？ → 是 → 滑动窗口（高频交易、风控校验）

2.7 金融场景实战选型建议