Token Bucket适合突发流量平滑处理，滑动窗口更精准控制单位时间请求数；两者可组合使用：网关层用Token Bucket做粗粒度保护，业务层用滑动窗口做细粒度控制。
在 Go 微服务中实现限流，核心是平衡系统稳定性与用户体验。Token Bucket 适合突发流量平滑处理，滑动窗口更精准控制单位时间请求数——两者不互斥，可按场景组合使用。
Token Bucket：简单高效，抗短时突发
令牌桶模型维护一个固定容量的“桶”，以恒定速率向桶中添加令牌，每个请求消耗一个令牌；桶满则丢弃新令牌，无令牌则拒绝请求。它天然支持突发流量（只要桶里有余量），实现轻量、无状态，适合网关层或单机限流。
推荐用 golang.org/x/time/rate 包：
rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示每 100ms 放 1 个令牌，初始桶容量为 5 —— 即允许最多 5 次瞬时请求在 HTTP handler 中调用 limiter.Allow()（非阻塞）或 limiter.Wait(ctx)（阻塞等待令牌）注意：该 limiter 是 goroutine-safe 的，但默认不跨进程共享；若需集群级限流，需配合 Redis + Lua 实现分布式令牌桶
滑动窗口：精确控频，适合统计类限流
滑动窗口将时间划分为小格（如 1 秒分 10 格，每格 100ms），只统计当前窗口内所有格子的请求数之和。相比固定窗口，它避免了临界突增问题（如 0:59.9s 到 1:00.1s 的两个请求不会被算作同一秒的 2 次）。
立即学习“go语言免费学习笔记（深入）”；
Go 中可手写轻量实现：
用 sync.Map 存储时间戳 → 计数，定期清理过期 key（或用带 TTL 的 LRU cache）更稳妥做法是用 Redis ZSET：每次请求 ZADD key timestamp timestamp，再 ZCOUNT key (now-60 now] 统计最近 60 秒请求数关键细节：窗口粒度越小，内存/Redis 压力越大；建议 1s 窗口配 10~100 个槽位，兼顾精度与开销
生产建议：分层+降级+可观测
真实微服务中，限流不是“开了就行”，而要融入整体稳定性体系：
网关层用 Token Bucket 做粗粒度保护（如 /api/user/* 全局 QPS ≤ 1000）业务层用滑动窗口做细粒度控制（如用户 ID 维度每分钟 ≤ 60 次调用）限流触发时返回标准错误码（如 429 Too Many Requests）和 Retry-After 头，便于客户端退避所有限流事件打日志 + 上报 metrics（如 Prometheus counter http_requests_limited_total{route=”user_get”,reason=”token_bucket”}）
基本上就这些。Token Bucket 上手快、开销低；滑动窗口精度高、逻辑稍重。选哪个不取决于技术炫酷，而看你的延迟敏感度、数据一致性要求和运维能力。
以上就是如何在Golang中实现微服务限流策略_使用Token Bucket和滑动窗口算法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1428806.html
微信扫一扫 
支付宝扫一扫 
