3. 限流算法基础（二）：令牌桶与漏桶

在金融交易系统中，限流算法的选择直接影响交易延迟、资源利用率和业务连续性。上一节我们介绍了计数器与滑动窗口算法，本节将深入讲解两种更精确、更平滑的限流算法——令牌桶（Token Bucket）与漏桶（Leaky Bucket），并分析它们在交易场景中的适用性。

3.1 令牌桶算法

3.1.1 原理与工作流程

令牌桶算法通过一个“桶”来存放令牌，系统以固定速率向桶中添加令牌，每个请求必须从桶中获取一个或多个令牌才能被处理。桶有最大容量，超出部分令牌被丢弃。

1. 初始化：桶容量为 capacity，初始令牌数为 capacity。
2. 令牌生成：以速率 rate 个/秒向桶中添加令牌，桶满则停止。
3. 请求处理：每个请求消耗 n 个令牌（通常 n=1）。若桶中令牌数 ≥ n，则放行并扣除令牌；否则拒绝或排队。
4. 突发处理：桶中积累的令牌允许短时间内的突发流量，最大突发量为桶容量。

3.1.2 数学建模

令牌桶的状态可用以下微分方程描述：

令 T(t) 为 t 时刻桶中令牌数，r 为令牌生成速率（个/秒），c 为桶容量。
令牌变化率：dT/dt = r - λ(t)
其中 λ(t) 为 t 时刻的请求消耗速率。
约束条件：0 ≤ T(t) ≤ c
请求放行条件：T(t) ≥ n（n 为请求消耗令牌数）

在离散时间系统中，常用以下更新公式：

# 伪代码：令牌桶状态更新
def token_bucket_update(last_time, current_time, tokens, rate, capacity):
    elapsed = current_time - last_time
    tokens = min(capacity, tokens + rate * elapsed)
    return tokens

3.1.3 令牌桶的典型应用

3.2 漏桶算法

3.2.1 原理与工作流程

漏桶算法将请求比作水滴，桶底部有一个固定速率的漏水孔。无论进水速率如何，出水速率始终保持恒定。桶有容量上限，超出部分的水（请求）直接溢出（被拒绝）。

1. 初始化：桶容量为 capacity，当前水量为 0。
2. 请求进入：每个请求相当于一滴水，加入桶中。若桶已满，请求被拒绝。
3. 恒定出水：以固定速率 rate 从桶底漏水，即处理请求。
4. 平滑输出：无论输入流量如何波动，输出流量始终 ≤ 出水速率。

3.2.2 数学建模

漏桶的状态可用以下模型描述：

令 W(t) 为 t 时刻桶中水量，r 为出水速率（请求/秒），c 为桶容量。
水量变化：dW/dt = λ_in(t) - r
其中 λ_in(t) 为输入请求速率。
约束条件：0 ≤ W(t) ≤ c
溢出条件：W(t) + 1 > c 时，新请求被丢弃
出水速率：恒定 r，不受输入影响

离散时间更新公式：

# 伪代码：漏桶状态更新
def leaky_bucket_update(last_time, current_time, water, rate, capacity):
    elapsed = current_time - last_time
    # 先漏水
    water = max(0, water - rate * elapsed)
    return water

3.2.3 漏桶的典型应用

3.3 令牌桶 vs 漏桶：对比分析

3.4 金融交易中的选型建议