首先使用令牌桶算法通过 rate.Limiter 实现单机限流，再结合 Redis + Lua 实现分布式全局限流，接着基于请求优先级配置动态策略，最后通过连接池、本地缓存和降级机制优化性能与容错，确保系统稳定性。
在高并发系统中，Golang 因其轻量级的 goroutine 和高效的调度机制，常被用于构建高性能服务。但并发请求过多时，可能压垮后端资源，导致系统雪崩。因此，实现合理的限流策略至关重要。本文介绍几种常见的 Golang 并发请求限流方案，并结合实际场景给出优化建议。
使用令牌桶实现基础限流
令牌桶算法是限流中最常用的模型之一。它以固定速率向桶中添加令牌，每次请求需获取一个令牌，若无可用令牌则拒绝或等待。
Go 标准库 golang.org/x/time/rate 提供了基于令牌桶的限流器 rate.Limiter，使用简单且线程安全。
- 初始化 limiter：每秒允许 100 个请求，突发容量为 200
- 在处理请求前调用 Allow() 或 Wait() 判断是否放行
- 适合控制单个服务实例的入口流量
示例代码：
立即学习“go语言免费学习笔记（深入）”；
import "golang.org/x/time/rate"
limiter := rate.NewLimiter(100, 200) // 100 QPS, burst 200
func handler(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
// 处理业务逻辑
}
分布式场景下的全局限流
单机限流无法应对多实例部署场景。当服务部署在多个节点时，总流量可能是单机限制的 N 倍，仍可能击穿数据库或依赖服务。
此时需要借助外部存储实现分布式限流，常用方案包括 Redis + Lua 脚本。
- 利用 Redis 的原子性操作，通过 Lua 脚本实现令牌桶或滑动窗口算法
- 每个请求先向 Redis 查询并更新计数，判断是否超限
- 注意网络延迟对性能的影响，可结合本地缓存做二级限流
例如使用 Redis 实现滑动窗口限流：
eval "local c = redis.call('GET', KEYS[1]); if c and tonumber(c) > tonumber(ARGV[1]) then return 0; else redis.call('INCR', KEYS[1]); redis.call('EXPIRE', KEYS[1], ARGV[2]); return 1; end" 1 rate.limit 100 60
表示 60 秒内最多 100 次请求。
鸿思特商城系统HstShop是一款B2C独立网店系统，由拥有十年互联网开发经验的牛头带队开发完成，完全免费开源，适合大中型网站平台快速构建立强大的网上商城平台网店系统。HstShop悉心听取每一位商家的需求与建议，根据中国人的购物习惯改进了购物流程，实现更好的用户购物体验。HstShop网店系统无论在产品功能、稳定性、执行效率、负载能力、安全性和搜索引擎优化等方面都居国内同类产品领先地位，成为国内
基于优先级的动态限流策略
并非所有请求都应同等对待。核心用户、关键接口应享有更高优先级。可通过请求上下文识别类型，并分配不同权重。
实现方式：
- 为不同用户或接口配置独立的限流规则
- 使用中间件解析请求头（如 API Key、User-ID）匹配策略
- 高优请求可走快速通道，低优请求提前拒绝或降级
例如：
if userID == "premium" {
premiumLimiter.Wait(ctx)
} else {
defaultLimiter.Allow()
}
这种细粒度控制能提升系统整体可用性和用户体验。
性能优化与容错设计
限流组件本身不能成为瓶颈。以下几点有助于提升稳定性和效率：
- 避免频繁远程调用：Redis 限流可启用连接池，减少网络开销
- 本地缓存+异步同步：本地维持近似计数，定期与中心节点校准
- 失败默认放行 or 拒绝？根据业务选择降级策略，防止因限流系统故障引发雪崩
- 监控和告警：记录被限流的请求量，及时发现异常流量
同时建议结合熔断机制（如使用 hystrix-go），在下游服务异常时主动降低负载。
基本上就这些。合理选择限流算法，结合业务特点设计策略，才能在保障系统稳定的前提下最大化服务能力。不复杂但容易忽略的是：限流不只是技术实现，更是容量规划的一部分。
