Sentinel集群限流揭秘：如何用“令牌中心”扛住百万流量？

为什么需要集群限流？

想象一下，你开了一家网红奶茶店，单店每天最多卖1000杯奶茶。如果开了三家分店，每家店独立限流1000杯，总销量最多3000杯。但若总店想控制整个品牌的“饥饿营销”，要求三店合计每天只卖2000杯——这就是集群限流的意义：从全局视角控制流量，避免单机限流的“各自为战”。

而Sentinel作为阿里开源的流量控制组件，正是通过集群限流解决了这一问题。它的核心思路是：设立一个“令牌中心”（Token Server）统一发放通行证，所有服务节点（Token Client）需先申请令牌才能处理请求。

---

Sentinel集群限流的三大核心原理

1. 令牌中心（Token Server）

   • 集群中唯一负责“发令牌”的节点，根据全局规则（如总QPS=1000）计算剩余令牌数。
   • 客户端（Token Client）处理请求前，需向Token Server申请令牌，若令牌不足则触发限流。

2. 两种部署模式

   • 内嵌式：从微服务集群中选一台机器兼任Token Server（省钱但需手动容灾）。
     • 优点：无需额外部署，适合单微服务集群。
     • 缺点：Token Server宕机需手动切换，可能影响业务性能。
   • 独立式：单独部署Token Server（稳定性高但成本增加）。
     • 优点：独立资源，适合跨微服务限流。
     • 缺点：需自行实现高可用（如多节点+负载均衡）。

3. 动态规则与通信机制

   • 客户端与服务端通过Netty通信，实时同步令牌状态。
   • 规则可动态更新（如通过Apollo配置中心），无需重启服务。

---

一个生活化案例：秒杀系统的限流设计

假设某电商平台要搞“iPhone秒杀”，需限制全集群每秒最多处理5000个请求：

1. 配置Token Server：独立部署一台高配置机器作为令牌中心。
2. 客户端集成：所有参与秒杀的服务节点作为Token Client，向Token Server申请令牌。
3. 规则设置：总QPS=5000，若某秒内请求超量，后续请求直接返回“秒杀失败”。

这样，即使某台服务节点突然涌入大量请求，也能通过集群限流避免系统崩溃。

---

集群限流的优缺点

• 优点：
  • 精准控制全局流量，避免单机限流的“木桶效应”。
  • 支持复杂场景（如按机器权重分配流量）。
• 缺点：
  • 故障转移需手动干预：Token Server宕机后，客户端不会自动切换（需依赖外部监控工具）。
  • 性能损耗：Token Server可能成为瓶颈（可通过独立部署+高性能网络优化）。

---

如何实现？三步搞定！

1. 部署Token Server：

   // 启动Token Server  
   ClusterServerConfigManager.loadGlobalTransportConfig(new ServerTransportConfig().setPort(9999));  
   

2. 配置客户端：

   // 指定Token Server地址  
   ClusterClientConfigManager.applyNewConfig(new ClusterClientConfig().setServerHost("192.168.1.100").setServerPort(9999));  
   

3. 设置集群规则（通过控制台或代码）：

   FlowRule rule = new FlowRule();  
   rule.setClusterMode(true); // 开启集群模式  
   rule.setCount(5000); // 总QPS=5000  
   

---

适用场景与总结

• 适合场景：高并发秒杀、API网关全局限流、多节点服务配额管理。
• 慎用场景：简单低频服务（单机限流更轻量）。

总结：
Sentinel的集群限流像“交通指挥中心”，通过集中管控令牌，确保流量洪峰下的系统稳定性。虽然手动容灾是其短板，但结合动态配置与独立部署，仍是分布式系统限流的首选方案。

---

延伸阅读：

• Sentinel官方文档
• 实战Demo：GitHub Sentinel集群限流示例