每一个限流都有一个阈值，如何确定这个阈值是一个难点。

服务器可能顶不住，定小了就误杀了，没有资源利用较大化，对用户体验不好。

我能想到的是，限制流量上线后，先估计一个大概的阈值，然后不执行真正的限制流量操作，而是采用日志记录的方式，分析和查看限制流量的效果，然后调整阈值，计算集群的总处理能力和每台机器的处理能力(方便扩展)。

然后重放在线流量，测试真正的限流效果，确定较终阈值，然后上线。

在此之前，我还看过一篇耗子叔的文章，讲的是在自动伸缩的情况下，我们很难动态调整限流阈值，所以基于TCP拥塞控制的思想，根据要求在一段时间内响应P90或P99值，确定此时服务器的健康状况，进行动态限流。该算法已在EaseGateway产品中实现，有兴趣的同学可自行搜索。

事实上，真实的商业场景非常复杂，需要限制流量的条件和资源很多，每个资源限制流量的要求也不同。因此，我上面是一个强大的国王。

限流组件

一般来说，我们不需要自己实现限流算法来达到限流的目的流量的目的，无论是接入层限制流量还是细粒度接口限制流量实际上都有现成的轮子使用，实际上也使用了上面提到的限制流量算法。

例如GoogleGuava提供的限流工具RateLimiter是基于令牌桶实现的，并扩展了算法，支持预热功能。

阿里开源限流框架Sentinel中的匀速排队限流策略采用了漏桶算法。

Nginx中的限流模块limit_req_zone采用漏桶算法，OpenResty中的resty.limit.req库等。

具体使用还是很简单的。感兴趣的学生可以自己搜索。对内部实现感兴趣的学生可以看看下一个源代码，学习如何实现生产级别的限流。