顾名思义,一个是针对单台服务器限流,一个是针对整个集群做限流。比如单机限100,那么就是单机最大就能抗100QPS,如果是集群限100,那么就意味着集群不管有多少台机器,总共 QPS 只能抗100。
单机限流非常好实现,比如用 guava 的 RateLimiter 就可以,通过控制每个服务实例的请求处理速率来保护服务的稳定性和可靠性。
集群限流通常需要使用分布式的限流算法和工具,比如 Redis、Sentinel、Hystrix等,以确保每个服务实例或节点都遵守全局的流量控制策略。
需要。
因为单机限流主要关注保护单个服务节点。即使集群级别有流量控制,单个实例依然可能因为本地的请求过多而出现性能问题或崩溃。
举个例子,集群10台机器,每台机器可以抗100QPS,一共就是1000,如果你集群限制1000QPS,那么平均每台是100。
但是这个"平均"只是理想情况,受限于负载均衡策略,相一旦流量不均匀了,某台机器的 QPS 就会比其他机器要高一些。
这种情况其实是非常常见的,尤其是在很多分布式系统中会有一些同机房优先、同单元优先等策略的影响下,很容易出现流量倾斜。
一旦只做了集群限流,而没有做单机限流,就可能把某台单机给打挂了。
还有就是,只有集群限流这种,你相当于不能有机器宕机或者下线,如果有部分机器下线了,那么平均下来单机的 QPS 就会上升,就有可能把一些单机给打挂。
而这种服务器下线在正常不过了,比如你应用发布过程中,就是会有一部分机器因发布而下线,那么就会出现问题。
一般来说也是需要的。
单机限流主要关注于保护单个服务实例不被本地请求压力过大而打挂。但是,整个服务集群可能面临的是全局的流量波动和峰值,需要集群级别的流量控制策略来确保整体系统的稳定性和可靠性。
尤其是在面对突发的大流量或者恶意攻击时,单个实例的限流策略可能不足以应对全局性的挑战。集群限流可以通过全局的流量监控和调整,协调各个节点的响应策略,有效地防止全局服务不可用。