背景
一个api接口/srm/api2/disabletime需要提供最大600qps的能力，超过600qps之后需要进行限流，返回429 http code。
现在业务节点一共20台，为了异地多活，分布在2机房gz和gz6,俩机房各十台机器上。
服务限流通常有以下俩种方式：
- 整个服务的每台业务机器上分别配置单独的qps值，这样只保证本机的并发量超过配置的qps值后就开始限流，所有机器的并大量总和也就是整个服务的并发量了。
- 服务的所有机器使用一个共享配置，例如共享redis。这样保证的是整个服务的并大量超过配置的共享qps之后才会限流。
俩种方式各有优点和缺点
- 第一种方式的优点：配置较为简单，qps控制粒度较为粗糙。缺点：配置的是单机的qps，往往业务节点的流量是不均匀的，这样就需要在理想qps上加一些buffer。
- 第二种方式的优点：配置的是整个服务的qps，不需要考虑业务节点的流量分部。缺点就是：新增类似的redis中间件，也就是增加系统的可维护性难度。
问题
本次实验就是使用的第一种方式，为了保证qps达到600之后能限流，所以理想情况下(也就是流量分部均匀的情况)每台机器的qps为30=600/20，但是实际情况发现，每天机器上的该api的请求量非常的不均，有的是个位数，有的达到了50多个。
sh online.sh 'grep '21:49:00' /home/work/odp_sds/log/webserver/access_log.2021122721 | grep 'disabletime' |wc -l'
[1/23] gz-cvm-lta-sds01.gz.sftcwl.com /home/01409103 [SUCCESS].
40
Continue (y/n):y
go on ...
[2/23] gz-cvm-lta-sds00.gz.sftcwl.com /home/01409103 [SUCCESS].
29
[3/23] gz-cvm-odp-sds31.gz.sftcwl.com /home/01409103 [SUCCESS].
10
[4/23] gz-cvm-odp-sds38.gz.sftcwl.com /home/01409103 [SUCCESS].
42
[5/23] gz-cvm-odp-sds30.gz.sftcwl.com /home/01409103 [SUCCESS].
50
[6/23] gz-cvm-odp-sds61.gz.sftcwl.com /home/01409103 [SUCCESS].
8
[7/23] gz-cvm-odp101.gz.sftcwl.com /home/01409103 [SUCCESS].
9
[8/23] gz-cvm-sds100.gz.sftcwl.com /home/01409103 [SUCCESS].
31
[9/23] gz-cvm-sds03.gz.sftcwl.com /home/01409103 [SUCCESS].
42
[10/23] gz-cvm-sds05.gz.sftcwl.com /home/01409103 [SUCCESS].
52
[11/23] gz6-cvm-sds4.gz.sftcwl.com /home/01409103 [SUCCESS].
50
[12/23] gz6-cvm-sds2.gz.sftcwl.com /home/01409103 [SUCCESS].
10
可能有人有疑惑，每个节点流量不均有什么影响呢？那我解释下。当整个服务的流量来了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左右，这也就间接的证明了上面的想法不对。
反思后的架构
上面俩张的流量分部印证了上面的架构是不对的，通过查询，正确的架构如下，可以看出和上面的架构图有几点不同
- vip不是一个，是每个机房有相同数据的vip，这样的话就可以看出流量在每个机房分布大致是相同的。
-
流量分部不均匀与slb的数量没有任何关系了
问题的确认
架构看起来是没问题，流量到最终端的业务节点也是均匀的，但是事实就是流量是不均匀的，我们结合实际情况来看下，比如轮训业务节点为a->b->c：
首先slb的轮训据指定url来轮训的，是根据整个服务的所有请求的来轮训的，比如第一个压测请求打到的是a业务节点，如果当前时间整个服务没有别的请求，那么第二个压测请求肯定会打到b业务节点，但实际情况是，当前时间肯定有别的请求，所以第二个压测请求时可能打到的还是a业务节点，也可能是b业务节点，可能是集群中的任何一个业务节点，我猜测就是这个原因导致了最终的流量不均匀。
为了证明这个猜想，我们可以看看21:49:00这个时间点所有机器上的所有请求是不是大致平均的，如果是平均的，则证明我们猜想正确。
sh online.sh 'grep '21:49:00' /home/work/odp_sds/log/webserver/access_log.2021122721 |wc -l'
[1/23] gz-cvm-lta-sds01.gz.sftcwl.com /home/01409103 [SUCCESS].
216
[2/23] gz-cvm-lta-sds00.gz.sftcwl.com /home/01409103 [SUCCESS].
219
[3/23] gz-cvm-odp-sds31.gz.sftcwl.com /home/01409103 [SUCCESS].
219
[4/23] gz-cvm-odp-sds38.gz.sftcwl.com /home/01409103 [SUCCESS].
207
[5/23] gz-cvm-odp-sds30.gz.sftcwl.com /home/01409103 [SUCCESS].
216
[6/23] gz-cvm-odp-sds61.gz.sftcwl.com /home/01409103 [SUCCESS].
219
[7/23] gz-cvm-odp101.gz.sftcwl.com /home/01409103 [SUCCESS].
215
[8/23] gz-cvm-sds100.gz.sftcwl.com /home/01409103 [SUCCESS].
219
[9/23] gz-cvm-sds03.gz.sftcwl.com /home/01409103 [SUCCESS].
214
[10/23] gz-cvm-sds05.gz.sftcwl.com /home/01409103 [SUCCESS].
217
可以看出所有机器的请求量大致基本相同，我们的猜想正确。
总结
使用第一种方式通常有个大前提：是各个机器流量分布必须非常均匀的，每台机器配置的qps=总qps/机器节点数量。但是由于网络总是不稳定性或者其他原因通常流量是不均匀的，所以需要每台节点配置的qps加一些Buffer，40或者50qps。
如果使用第二种方式的话，我们直接在redis配置600qps即可，因为不需要关注每台机器流量的流量分布，管你节点的流量是50还8呢，只要总和大于600qps后，服务就会触发限流了。
如果第二种方式能够实现，建议使用第二种方式。
