浅谈限流组件的应用

[破茧边缘]

首先了解一下业界常用的限流组件：单机版的有：JDK自带的锁、信号量等，Guava的RateLimiter；分布式的包括Redis、Redis-cell、Redisson（基于lua脚本实现）、Sentinel、Hystrix。

并且在所有任务之前你需要明确你的业务要限流的对象是什么。比如你的服务是单体的，那其实用单机限流正合适。但是现在这个时代的单体业务存在的并不多了，只有一些小项目用的比较多。

还有一种情况就是不需要在业务层面精确限流，比如说我们的业务部署在多个机器或者容器上，对外以Http的形式暴露服务，并且在Nginx层做了一定的负载均衡，导致流量会比较均匀地分布到各台机器上，此时用单机限流也是不错的：只要每台机器的流量都限制住，整体的流量就是被限制的。注意这里是近似，试想，如果我们的机器数量扩容了一倍，那整体的限流阈值就会增长一倍。所以说，单机限流阈值也常用来保护机器不被打崩，考虑的角度更多是机器的性能，而非细化到某个业务接口。

如果要精确限制某个业务接口的流量，服务暴露形式不限，可能是Http，也可能是RPC，在分布式部署的环境下就需要采用分布式限流的方案了。国内少数公司采用Netflix开源的Hystrix实现限流功能，还有一些公司直接引入了阿里开源的Sentinel来用，还有一些公司会使用Redisson提供的限流能力，或者直接编写Lua脚本实现。当然，还有一些大厂会自研限流组件，更好地满足自身业务需求。

限流的维度是什么呢？这个问题直接决定了限流功能要在哪个层面来实现。比如针对Http接口，限流器可以配置在Nginx层，进行域名限流。作为面向用户端防火墙的一个基础组件。也可以下放到业务接口层，限制某个业务的流量。再进一步，如果我们要根据特定的接口参数进行限流（比如限制每个用户在一段时间内请求某个接口的频率），那限流组件就需要在接口层面实现了。

限流该用什么算法呢？常见的有固定窗口法、漏斗法，以及令牌桶法，还有一些组件实现了具有预热功能的算法。现实场景中，出于应对突发流量的考虑，令牌桶算法的应用更为广泛。这个问题网上谈的比较多，不再赘述了。

限流数据要保存在哪里？这个问题的答案依赖于具体的实现方案。比如我们如果用基于Redis发展出来的组件（比如Redis-cell、Redisson）来实现，限流数据就是存在Redis服务器中的。而如果采用Sentinel实现，限流数据就是存在内存中的。
限流数据量的控制。这个问题的解决方案依赖于限流对象的数量。如果是针对有限的几个接口做限流，数据量小到几乎可以不用考虑。但如果是前面提到的“根据特定的业务参数进行限流”这种场景，就可能出现问题：比如针对用户ID做限流，那可能需要保存对应量级的限流数据，每个正在访问的用户都要记录访问频次。