OpenClaw技能限流实战：从原理到高并发场景下的最佳实践

4次阅读

共计 1609 个字符，预计需要花费 5 分钟才能阅读完成。

在 OpenClaw 平台上集成第三方技能时，我们经常遇到这样的场景：某个技能突然被高频调用，导致服务器 CPU 飙升至 100%，后续请求全部超时。更糟糕的是，这种故障会像多米诺骨牌一样引发雪崩效应——一个技能的崩溃可能导致整个平台不可用。

通过监控数据可以看到：

无限制流时，单个技能实例的 QPS 可能从 50 突然飙升到 2000+
数据库连接池在 30 秒内被耗尽
平均响应时间从 200ms 恶化到 15 秒以上

像物理漏桶一样恒定速率处理请求：

优点：绝对平滑的流量输出
缺点：无法应对突发流量，导致资源利用率低

统计最近 N 秒内的请求量：

优点：精度较高
缺点：内存占用随精度提升而增加

我们最终选择的方案 ，因为：

允许短时突发流量（桶内有令牌时）
内存占用恒定
算法复杂度 O(1)

// TokenBucket 限流器结构体
type TokenBucket struct {
    capacity  int64         // 桶容量
    rate      time.Duration // 添加速率
    tokens    int64         // 当前令牌数
    lastCheck time.Time     // 最后检查时间
    mu        sync.Mutex    // 细粒度锁
}

// Allow 判断是否允许请求
func (tb *TokenBucket) Allow() bool {tb.mu.Lock()
    defer tb.mu.Unlock()

    now := time.Now()
    // 计算这段时间应该添加的令牌数
    elapsed := now.Sub(tb.lastCheck)
    addTokens := int64(elapsed / tb.rate)

    if addTokens > 0 {tb.tokens = min(tb.tokens+addTokens, tb.capacity)
        tb.lastCheck = now
    }

    if tb.tokens > 0 {
        tb.tokens--
        return true
    }
    return false
}

关键优化点：

使用 sync.Mutex 而非全局锁
只在取令牌时计算时间差，避免定时器开销
原子操作减少锁竞争时间

-- Redis Lua 脚本实现原子操作
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local current = tonumber(redis.call('get', key) or "0")

if current + 1 > limit then
    return 0
else
    redis.call("INCRBY", key, 1)
    redis.call("EXPIRE", key, 10)
    return 1
end

当拒绝率持续 30 秒 >20% 时触发熔断

Prometheus 指标示例：

# HELP skill_request_total Total skill requests
# TYPE skill_request_total counter
skill_request_total{skill="weather",status="200"} 3421
skill_request_total{skill="weather",status="429"} 127