关于集群问题限流的一点思路

发表于 2020-03-11 更新于 2024-04-10 分类于樱桃沟阅读次数：本文字数： 1.5k 阅读时长 ≈ 1 分钟

问题是我们需要做一个统一的限流层，而这个限流层肯定不是单机可以完成，必定是一个多级多机的集群来处理。
因此肯定会涉及到共享存储的事情。我们一般都使用redis，但是其实redis涉及到单核上限的问题，其实更好的应该还是memcache，很多公司都改良过memecache也都开源出来的。

限流性能考量

网上有一堆关于nginx限流的文章。

用到的算法基本就两种，漏桶算法和令牌桶算法。

漏桶算法更关注的是一个速率的，而令牌桶算法就是更关注整体的容量。

但是当我们一个要限速每秒10万，这个时候我们不可能每来一个请求就去请求redis一下，这样不光是redis承受不了，整个网络IO更是如此，就算使用redis集群也有上限的。

所以我们的目标就是降低操作数据的次数。这样就可以降低网络IO和数据操作次数。

那现在的思路就是假设要限流10万次每秒。我们将10万除以100，得到了1000次。每内部计数到1000次再通过网络去操作一下数据。

如上图所示的。但是这种做法就是不精确。最坏情况就是有4%的误差，也就是机器个数的百分比。这个看各自的需求吧，如果受不了那就改成千分比，不过那样操作次数就会多了点。

理论上是这样的，但是做起来就看看现在有没有现有的轮子，毕竟直接在nginx的代码里改有点难度，还是直接上lua版本的。

上面这3个都可以参考下，到底是redis操作还是直接内部sync可以再考虑。不一定redis的就比sync的好。

整体思路就是按照令牌桶的策略，我们更关注的是整体容量，间隔区间200ms还是100ms其实对于后端影响并不大。

但是这个是后端，后面还需要有个管理界面去做这个。

简单点的就用现有的Jenkins去完成，但是这个功能有限，仅有的就是查询下操作历史。现有状态什么都要从自己去实现下。

那就撸个管理后台。大体包含的功能如下

每个API都有自己的上限标准。
然后每个rest也都有自己的上限标准。
给单个客户加的限流标准不能超过整体限流的100%，提示需要扩容。

每个客户可以有10个限流标准。
限流标准不支持时间计划：比如1~~2点是并发100， 2~~3点是并发200这种标准。
限流维度支持多个维度关联，最少也要2个维度关联。

返回status 429，内容为（nginx rate limit）·
给支持和销售发对应邮件，提示该客户已经超了限流，需要购买提升现有限流标准。提示信息每小时发一次，防止邮件风暴。

展示单个客户的限流规则
展示默认的限流规则
展示整个系统的限流和现有的剩余。

这个就按照openldap的分组来就行了。就读写2个分组。