Gin+Sentinel 限流全解：5大系统限流策略区别与生产最佳实践

码说AI

366人浏览 · 2026-04-29 10:09:32

码说AI · 2026-04-29 10:09:32 发布

一、前言

在后端开发中，接口限流是高并发服务的基石，主要用于防止流量突增、恶意刷接口导致服务器、数据库崩溃。

目前 Go 语言 Gin 框架最主流的限流方案就是 Alibaba Sentinel，轻量、无侵入、支持多种限流策略，适配绝大多数生产场景。

很多同学只会无脑使用 BBR 自适应限流，但并不了解 Sentinel 所有系统限流策略，无法根据业务场景选型。本文结合真实项目代码，全方位讲解 Sentinel 五大限流策略、适用场景、优缺点以及生产最佳配置。

二、项目原生限流代码

先看我们项目中正在使用的 Gin 限流中间件，也是大部分 Go 后台项目的通用模板：

import (
	"github.com/alibaba/sentinel-golang/core/system"
	sentinel "github.com/alibaba/sentinel-golang/pkg/adapters/gin"
	"github.com/gin-gonic/gin"

	log "github.com/go-admin-team/go-admin-core/logger"
)

// Sentinel 限流中间件
func Sentinel() gin.HandlerFunc {
	if _, err := system.LoadRules([]*system.Rule{
		{
			MetricType:   system.InboundQPS,
			TriggerCount: 200,
			Strategy:     system.BBR,
		},
	}); err != nil {
		log.Fatalf("Unexpected error: %+v", err)
	}
	return sentinel.SentinelMiddleware(
		sentinel.WithBlockFallback(func(ctx *gin.Context) {
			ctx.AbortWithStatusJSON(200, map[string]interface{}{
				"msg":  "too many request; the quota used up!",
				"code": 500,
			})
		}),
	)
}

代码核心逻辑：配置入口QPS限流，阈值200，采用BBR自适应策略，流量超限后拦截请求并返回自定义提示。

三、Sentinel 五大系统限流策略详解

Sentinel 系统级限流一共提供 5 种核心策略，覆盖服务器负载、硬件资源、请求流量、并发数等全维度防护，下面逐一拆解。

1、InboundQPS（入口QPS限流）

核心作用：限制服务每秒接收的最大请求数。

配置示例：

{
    MetricType:   system.InboundQPS,
    TriggerCount: 200, // 每秒最多200个请求
    Strategy:     system.BBR,
}

适用场景：防接口刷量、秒杀接口、对外开放的公共接口

优缺点：规则简单直观，但属于固定阈值，无法根据服务器硬件压力动态调整，服务器负载高时依然可能崩溃。

2、Concurrency（并发数限流）

核心作用：限制服务同时正在执行的请求数量，而非每秒请求数。

适用场景：慢查询接口、文件导出、数据库批量操作等耗时接口

优缺点：专门解决接口阻塞、请求堆积问题，有效防止连接池占满；缺点是无法限制瞬时高频短请求。

3、CPU（CPU使用率限流）

核心作用：根据服务器CPU使用率触发限流。

常规阈值：80（代表CPU使用率80%）

适用场景：CPU密集型服务、计算型接口

优缺点：贴合服务器硬件状态，稳定性高；缺点是无法防护内存溢出、流量攻击场景。

4、Load（系统负载限流）

核心作用：基于 Linux 系统负载阈值限流，Load 值代表系统任务等待队列数量。

常规阈值：单核服务器阈值5，多核可按需调高

适用场景：高并发、多任务排队的后端服务

5、Mem（内存使用率限流）

核心作用：监控服务器内存占用，超出阈值触发限流。

常规阈值：80（内存使用率80%）

适用场景：图片处理、文件解析、大报文接收等内存消耗高的服务。

6、BBR 自适应限流（重点）

BBR 不属于独立的指标类型，而是 最优的限流算法策略，也是生产环境首选。

原理：综合服务器CPU、负载、响应延迟、请求堆积情况，动态计算限流阈值，无需手动固定QPS。

优势：流量小的时候完全不限流，流量暴涨、服务器压力大时自动限流，兼顾可用性与安全性。

四、五大限流策略对比表

限流策略	监控维度	适用场景	生产推荐度
InboundQPS	每秒请求数	防刷、秒杀、公共接口	⭐⭐⭐⭐
Concurrency	并发请求数	慢接口、数据库操作接口	⭐⭐⭐⭐
CPU	CPU使用率	计算型、CPU密集服务	⭐⭐⭐⭐⭐
Load	系统负载	通用后端服务	⭐⭐⭐
Mem	内存使用率	文件、图片处理服务	⭐⭐⭐
BBR	综合硬件+流量	所有线上业务服务	⭐⭐⭐⭐⭐

五、代码缺陷优化（生产规范）

原项目代码存在一个不规范问题：限流场景标准 HTTP 状态码应为 429 Too Many Requests，原代码返回200状态码，会导致前端、日志监控识别异常。

优化后完整生产可用代码：

func Sentinel() gin.HandlerFunc {
	if _, err := system.LoadRules([]*system.Rule{
		{
			MetricType:   system.InboundQPS,
			TriggerCount: 2000,
			Strategy:     system.BBR,
		},
	}); err != nil {
		log.Fatalf("加载限流规则失败: %+v", err)
	}
	return sentinel.SentinelMiddleware(
		sentinel.WithBlockFallback(func(ctx *gin.Context) {
			// 规范限流返回：429状态码
			ctx.AbortWithStatusJSON(429, map[string]interface{}{
				"msg":  "服务器繁忙，访问人数过多，请稍后重试",
				"code": 429,
			})
		}),
	)
}