“基础架构部的限流4--集群限流”，续上，对于保护api网关背后的应用，应用背后的数据库，下游服务时，需要设定一个集群的总限流数。

自然的想法是引入一个全局的计数器如redis，但这全局的计数器势必成为一个中央瓶颈，在qps数不高的场景，如分钟级限流等等可以直接使用，各种玩法就不啰嗦了。

但对于高qps的场景，就不适合了。

如果负载均衡大致均匀，可以监听api网关集群，服务集群的数量，然后把总限流值除一下，得到单机限流值，然后继续本地限流就好了。

但还有一种情况，流量经过网关前面的四层负载均衡时，不认识哪个和哪个api，所以不会按api级别来做负载均衡，所以在api层面上，流量是不均匀的。

此时像阿里Sentinel好像就回归中央计数器的模式，但我们还是忍不了性能损耗和大量额外的计数器部署资源，所以设计思路如下：

1.真正触发限流的情况还是少，极度不均匀的情况也是少，所以尽量还是让限流在本地运行。

2.即使发生与中央服务器的交互，也是一个批量操作，类似以前讲的唯一id生成器。

3.中央服务器后面不再挂redis了，而是jvm内存中的计数器，使用我们的微服务框架的路由功能，让同一个计数器总是哈希路由到同一个服务器上。服务器挂了就挂了，毕竟只是个秒级的计数器。

具体实现我们设计的很复杂，一个简单粗糙些的版本，假如10台机的集群限流一万，平均下来单机一千，那本地可以执行七百的限流，剩下三千在中央存着。当本地七百的额度花光，就每次从中央再申请一百的额度。

三七开是个例子，视力流量不均匀的程度，也可以五五开，八二开。每次从中央拿10%还是20%，也可以视中央服务器压力而配置。

限流四篇就写完了，写微博果然比写公号轻松。

继续Renata Gubaeva，继续画画的主题。 #程序员#