一次限流的引发思考

一个api接口 /srm/api2/disabletime 需要提供最大600qps的能力，超过600qps之后需要进行限流，返回429 http code。

现在业务节点一共20台，为了异地多活，分布在2机房gz和gz6,俩机房各十台机器上。

服务限流通常有以下俩种方式：

俩种方式各有优点和缺点

本次实验就是使用的第一种方式，为了保证qps达到600之后能限流，所以理想情况下(也就是流量分部均匀的情况)每台机器的qps为30=600/20，但是实际情况发现，每天机器上的该api的请求量非常的不均，有的是个位数，有的达到了50多个。

可能有人有疑惑，每个节点流量不均有什么影响呢？那我解释下。当整个服务的流量来了600qps时，由于流量不均，有的节点流量分布是40或者50的请求量，有的节点是个位数8，5的请求量。现在每台机器的配置的qps为30，那么大于30qps的那些节点就出触发限流了，最终导致整个服务没有达到600qps时就触发限流了。

想要了解流量为什么不均匀，需要首先搞清楚业务整体架构。

最初理解的架构如下，可以很明显的发现，在gz和gz6俩机房的slb数量不一致，也就导致了gz的业务机器流量大于gz6的业务机器流量。

理论上 ,gz 的 slb流量会发给 gz 的 nginx,gz6 的slb流量会发给 gz6 的 nginx。腾讯云的负载均衡，发给 slb 的流量，不区分 gz 与 gz6 ，在所有 slb 的机器里执行轮询策略的负载均衡。

那么gz 的 slb 机器数量比 gz6 多，那 gz机房获得的流量就比 gz6机房多， gz 的 nignx获得的流量就比 gz6的nginx多。

上面解释看似合理，结论就是：由于gz和gz6俩机房的业务节点数量相同，而gz和gz6的slb的数量不同， 最终导致了俩机房的流量不均，进而导致了gz和gz6的业务节点的流量不均 。

下图是对接口压测2分钟，每秒600qps的流量趋势图，可以出在gz和gz6的流量大致分部均匀，大致在300Qps左右，这也就间接的证明了上面的想法不对。

上面俩张的流量分部印证了上面的架构是不对的，通过查询，正确的架构如下，可以看出和上面的架构图有几点不同

架构看起来是没问题，流量到最终端的业务节点也是均匀的，但是事实就是流量是不均匀的，我们结合实际情况来看下，比如轮训业务节点为a->b->c：

首先slb的轮训 据指定url来轮训 的，是 根据整个服务的所有请求 的来轮训的 ，比如第一个压测请求打到的是a业务节点，如果当前时间整个服务没有别的请求，那么第二个压测请求肯定会打到b业务节点，但实际情况是，当前时间肯定有别的请求，所以第二个压测请求时可能打到的还是a业务节点，也可能是b业务节点，可能是集群中的任何一个业务节点，我猜测就是这个原因导致了最终的流量不均匀。

为了证明这个猜想，我们可以看看 21:49:00 这个时间点所有机器上的所有请求是不是大致平均的，如果是平均的，则证明我们猜想正确。

可以看出所有机器的请求量大致基本相同，我们的猜想正确。

使用第一种方式通常有个大前提： 是各个机器流量分布必须非常均匀的，每台机器配置的qps=总qps/机器节点数量。但是由于网络总是不稳定性或者其他原因通常流量是不均匀的，所以需要每台节点配置的qps加一些Buffer，40或者50qps 。

如果使用第二种方式的话，我们直接在redis配置600qps即可，因为不需要关注每台机器流量的流量分布，管你节点的流量是50还8呢，只要总和大于600qps后，服务就会触发限流了。

如果第二种方式能够实现，建议使用第二种方式。

参考官网Haproxy的配置手册 HAProxy Configuration Manual ， 我们可以利用http_req_rate这个配置项实现限流，如下图所示：

Marathon-LB（MLB）是一个根据Marathon应用状态自动调整和配置HAProxy的工具。Marathon-LB既可以用作服务代理，也可以用作负载均衡和服务发现工具。

参考github MLB的 Templates信息 ，我们可以利用HAPROXY_0_BACKEND_HTTP_OPTIONS 这个模板修改服务backend部分的信息，如下图所示：

利用marathon发布服务blackname,marathon.json中配置label如下：

"HAPROXY_0_BACKEND_HTTP_OPTIONS": " stick-table type ip  size 200k  expire 60s store conn_rate(30s) , bytes_out_rate(30s) \n tcp-request content  track-sc2 src  \n acl conn_rate_abuse  sc2_conn_rate gt 5  \n acl data_rate_abuse  sc2_bytes_out_rate  gt 20000000 \n http-request deny  if conn_rate_abuse \n http-request deny  if data_rate_abuse \n"

MLB会动态监控marathon的事件流，动态生成Haproxy的配置文件。经过上面的配置，在浏览器30S之内访问次数大于5 次会断开TCP连接。如下图所示：

限流本质上是减少流量的访问，而服务的处理能力不变

互联网项目是面对广大用户的，在高并发场景下，因为请求过多，对将压力转移至服务器，容易对服务器造成极大压力甚至故障，所以需要通过 限流来对服务器进行保护。

一、 大量用户高频率访问情况下，导致服务器承受不住压力而宕机。

二、 恶意请求高频率访问服务器，导致服务器造成宕机。

三、 对于网页爬虫请求，我们需要对访问进行限流

---