Go 令牌桶限流实战：用 time.Ticker 保护高频接口

接口平时很稳，一到活动页刷新、脚本误刷、移动端网络抖动重试，就突然出现数据库连接飙升、缓存被打满、下游接口超时。限流的目标不是让系统“拒绝所有请求”，而是在高峰时按可承受的速率放行，把超过能力的请求尽早挡在入口。

适合人群：已经会写 Go HTTP 服务，想给登录、下单、短信发送、报表导出等高频接口加一层轻量保护的同学。本文只使用标准库，便于理解令牌桶的核心逻辑。

目录

• 为什么要在入口做限流
• 令牌桶的工作方式
• 用 Go 实现一个轻量限流器
• 接入 HTTP 中间件
• 指标和常见坑

一、为什么要在入口做限流

没有限流时，所有请求都会进入业务代码。只要下游资源先撑不住，问题就会从一个接口扩散到整个服务：连接池被占满、慢请求堆积、正常用户也无法访问。入口限流可以提前判断“系统现在还能不能接”，把拒绝成本控制在最小范围内。

常见需要限流的接口包括：

• 登录、注册、验证码发送等容易被刷的入口。
• 下单、支付确认、库存查询等依赖核心资源的链路。
• 导出、搜索、统计报表等单次成本较高的接口。

二、令牌桶的工作方式

令牌桶可以理解成一个容量有限的小桶：后台按固定速度往桶里放令牌，每个请求进来时尝试拿一个令牌；拿到就放行，拿不到就拒绝或稍后再试。桶容量决定允许的突发峰值，补充速率决定长期吞吐。

比如桶容量是 10，补充速率是每秒 5 个令牌。平稳情况下，每秒最多放行 5 个请求；如果之前比较空闲，桶里攒了 10 个令牌，就可以承受一次短暂突发，但突发过后仍会回到每秒 5 个的节奏。

三、用 Go 实现一个轻量限流器

下面的实现使用带缓冲的 channel 表示令牌桶，用 `time.Ticker` 定时补充令牌。`Allow` 方法不等待，能拿到令牌就返回 true，拿不到就返回 false。

package main

import (
    "context"
    "sync"
    "time"
)

type TokenBucket struct {
    tokens chan struct{}
    stop   chan struct{}
    once   sync.Once
}

func NewTokenBucket(capacity int, refillEvery time.Duration) *TokenBucket {
    bucket := &TokenBucket{
        tokens: make(chan struct{}, capacity),
        stop:   make(chan struct{}),
    }

    for i := 0; i 

这里的 `refillEvery` 是“多久补一个令牌”。如果设置为 200 毫秒，就相当于每秒最多补 5 个令牌。桶满时补充会被丢弃，避免令牌无限堆积。

四、接入 HTTP 中间件

限流器通常放在中间件里。请求进来后先判断是否允许访问，拿不到令牌就直接返回 429，拿到令牌再交给后面的业务处理。

package main

import (
    "fmt"
    "net/http"
    "time"
)

func RateLimit(bucket *TokenBucket, next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !bucket.Allow() {
            w.Header().Set("Retry-After", "1")
            http.Error(w, "too many requests", http.StatusTooManyRequests)
            return
        }
        next.ServeHTTP(w, r)
    })
}

func hello(w http.ResponseWriter, r *http.Request) {
    _, _ = fmt.Fprintln(w, "hello 17golang")
}

func buildServer() *http.Server {
    bucket := NewTokenBucket(20, 100*time.Millisecond)
    mux := http.NewServeMux()
    mux.Handle("/", RateLimit(bucket, http.HandlerFunc(hello)))

    return &http.Server{
        Addr:              ":8080",
        Handler:           mux,
        ReadHeaderTimeout: 3 * time.Second,
    }
}

这份中间件是全局限流。真实业务里可以按接口、用户、IP、租户分别设置不同桶。比如短信接口更严格，普通查询接口宽松一些。

五、指标和常见坑

1. 不要只看成功请求数

限流上线后要同时观察放行数、拒绝数、接口耗时、下游连接池占用。如果拒绝数突然升高，说明入口压力变大，或者桶参数设置太小。

2. 桶容量不是越大越好

桶容量越大，允许的瞬时突发越高。容量过大会让突发流量直接冲到下游，失去保护意义。建议从下游资源能承受的峰值反推。

3. 单机限流不等于集群总限流

上面的实现是单进程内限流。如果服务部署 10 个实例，每个实例每秒放行 50 个请求，集群总放行量就是大约每秒 500 个。需要全局配额时，要结合网关或集中式计数。

4. 上线前自测清单

• 低并发访问时全部放行，接口耗时没有明显增加。
• 高并发访问时出现 429，下游数据库和缓存保持稳定。
• 桶容量和补充速率可以通过配置调整。
• 日志里能看到限流发生的接口、来源和次数。

总结

Go 里用 `time.Ticker` 和 channel 就能实现一个容易理解的令牌桶。落地时记住两件事：桶容量控制突发，补充速率控制长期吞吐。把它放到 HTTP 中间件后，入口就能先挡住超过系统承受能力的请求，让下游资源保持在稳定区间。