Sentinel 是怎么实现集群限流的？
- 标签：Spring Cloud、微服务、后端、服务容灾、Sentinel
🏛 业务架构师
Sentinel 集群限流的核心思想：选一个 Token Server 集中发放令牌，各客户端节点向它申请，全局额度统一管控——解决单机限流在多实例下"额度翻倍"的问题（单机 100 QPS × 10 实例 = 1000 QPS，远超全局目标 300）。
架构模式（两种）：
- 独立 Token Server 部署：专门的集群（可集群化 HA），所有应用节点作为 client 连接它取令牌——跨多个服务做全局流控时用；
- 内嵌模式（嵌入式）：选某个应用实例当选主充当 Token Server（自动选举、故障转移）——部署简单，单服务的集群流控首选，省一套集群运维。
工作机制：本地节点批量申请令牌（减少网络往返），Token Server 维护全局队列按令牌桶匀速发放；server 不可达时自动退化回单机限流——这个 fail-back 设计很关键，限流组件自身故障不能变成业务故障。
业务架构师视角的取舍判断：
- 先问需不需要集群限流：流量入口在网关统一限流（Gateway + Redis）往往更简单——"全局额度控制"放入口做，服务内 Sentinel 单机限流兜底，两层配合多数场景够用；
- 集群限流的真实需求场景：对下游有全局配额承诺时（调用第三方接口额度 1000 QPS、数据库整体水位）——这时候必须全局统一计数；
- 代价清单：Token Server 的部署与高可用、批量申请的粒度（批量太大损失精度、太小网络开销大）——精度与复杂度是反向的，按业务容忍度选。
一句话：单机限流保命，集群限流保承诺，别为不需要的精度多养一套集群。
🏗 系统架构师
问题背景：单机限流按「总阈值 ÷ 实例数」分配会失真——负载不均时有的实例先死；且保护共享资源需要全局视角（DB 总容量 5000 QPS 不等于每实例各限 1000，还有别的服务在打）。
机制：Token Server 集中发牌——集群选一个节点做 token server（或独立部署），各节点请求前向它申请令牌（支持批量预取摊薄 RPC），server 维护全局计数判断放行。
部署形态：
- 嵌入模式：token server 嵌在某个应用实例（省资源，但该实例故障要 failover，不适合大集群）；
- 独立模式：专门部署 token server 集群（推荐大流量场景，支持 namespace 配额管理）。
架构权衡（必讲）：
- 精确性换可用性：每请求多一次 token 交互（内网 1ms 级，批量预取摊薄）；token server 故障时默认 fail-open 退化为单机限流——保可用舍精确，这个取舍必须显式认可；
- 替代方案：网关统一限流（管总量不管内部）、Redis 加 Lua（实现简单，但多一跳网络且 Redis 扛压力）；
- 我的实践：分层——网关总量限流加单机兜底；集群精确限流只用于保护 DB、第三方配额这类必须全局视角的场景。
💻 全栈开发专家
背景：单机限流 100 QPS × 10 台 = 1000 的算法在流量不均时不成立（LB 偏差、机器性能差异）——精确总量控制需要全局视角，这就是集群限流。
架构：Token Server（令牌服务端）+ Token Client（应用实例内嵌客户端）。流程：请求到达 → 实例里的 Token Client 向 Token Server 申请令牌（带命名空间、规则 ID、token 数）→ Server 按全局规则（如全局限 1000 QPS）统一配额发放 → 拿到令牌放行，拿不到 block。
两种部署形态：
- 嵌入式：Token Server 跑在某个应用实例里，省部署；该实例挂了集群限流失效
- 独立部署：专用 Token Server 集群（生产推荐），namespace 隔离、多应用共用
生产必做的兜底：Token Server 失联时降级为本地限流（配置 failback 策略与超时）——否则限流组件自己成了单点，这是我评估集群限流时永远先问的行为。
适用判断：总配额型需求（给租户全局 500 QPS、保护共享 DB）才值得集群流控的复杂度；普通服务保护，单机限流 + 自动扩缩容已经够用。