微服务限流核心是控制单位时间请求数，Golang常用令牌桶（rate.Limiter）和滑动窗口（Redis+Lua），需结合分布式协同、降级策略及可观测性。
在微服务架构中，限流是保障系统稳定性的关键手段。Golang 因其高并发特性和轻量级协程（goroutine），非常适合实现高效、低开销的限流逻辑。核心思路是控制单位时间内允许通过的请求数量，防止突发流量压垮下游服务或数据库。
令牌桶算法：平滑限流，适合突发流量
令牌桶是最常用且直观的限流模型：以固定速率向桶中添加令牌，每个请求需消耗一个令牌；桶满则丢弃新令牌，无令牌则拒绝请求。Go 标准库 golang.org/x/time/rate 提供了开箱即用的 rate.Limiter，底层即基于令牌桶。
- 初始化：使用 rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示每 100ms 放入 1 个令牌，桶容量为 5（即最多允许 5 个请求“排队”等待）
- 拦截请求：在 HTTP handler 中调用 limiter.Allow()（非阻塞）或 limiter.Wait(ctx)（阻塞等待可用令牌）
- 注意：Limiter 是并发安全的，可全局复用，无需为每个请求新建
滑动窗口计数：精准统计，避免桶边界误差
令牌桶在窗口切换时可能放行略多请求（如上一秒末尾 + 下一秒开头）。若需严格限制“最近 1 秒内最多 100 次”，滑动窗口更准确。常见做法是用 Redis 的 ZSET 或本地内存 + 定时清理。
- 简单内存版：用 map[string][]time.Time 记录每个 key（如用户 ID 或 IP）的请求时间戳切片，每次请求前清理过期时间戳并检查长度
- 生产推荐：结合 Redis + Lua 脚本（如 eval "redis.call('zrembylex', KEYS[1], '-', ARGV[1]); return redis.call('zcard', KEYS[1])" 1 my:window 0 1000），保证原子性与分布式一致性
分布式限流：跨实例协同，避免单点过载
单机限流只保护本进程，集群环境下需统一决策。关键在于共享状态与低延迟访问。
立即学习“go语言免费学习笔记（深入）”；
- Redis + Lua 是主流选择：将窗口计数、令牌更新等逻辑封装进脚本，一次网络请求完成判断与更新
- 可选中间件：如使用 go-redsync 实现分布式锁配合计数器，但性能低于 Lua 原子操作
- 注意降级：Redis 不可用时，应自动 fallback 到本地限流（如令牌桶），避免全站雪崩
组合策略与可观测性：不止于“挡请求”
真实场景中，限流需配合熔断、降级与监控，形成完整防护链。
- 分层限流：API 网关层（按 IP/用户限流）、服务入口层（按接口 QPS）、DB 访问层（连接池 + 查询超时）
- 动态调整：通过配置中心（如 Nacos、Consul）实时修改限流阈值，无需重启服务
- 埋点上报：记录被限流次数、响应码（如 429）、触发规则，接入 Prometheus + Grafana 做阈值告警
