分布式限频组件设计思路

分布式限频组件

如果需要你设计一个分布式限频组件，你会怎么做，将考虑哪些方面的内容？
笔者整理自己对限频组件的理解，总结一些设计思路，希望与大家探讨。

明确需求

调用流程

在微服务的入口，把上游请求包拆解鉴权后，进行流量限制校验，流量校验通过的请求继续执行，否则返回流量限频。

请求路由

按client端的路由方式分类，一般分为三种：

固定路由

固定路由标识同样的请求只会路由到对应的一台Server

分组路由

将后端server分组，同样的请求只会路由到某一组机器

随机路由

请求可以随机路由到后端任一台Server

三者请求的可用性是逐渐提高的：
如固定路由：当后端svr服务挂掉时，该组所有请求都将不能正常运行。
当然也可以采取降级措施：比如在后端服务异常时，可以降级路由到其他的机器，从而提升整体的可用性。
请求能路由到其他机器的前提：服务器是无状态的，如果在server上有数据如限额组件缓存数据，则不可以更换路由规则。

性能要求

限频组件要求可用性

限频前者指的是频率限制，比如是api限频，异常时有超出部分也能接受请求，限频失败的话会导致下游有短暂积压，在系统的容错性范围内即可。
结论：内存缓存即可，数据不用落地存储。

限额组件要求强一致性

限频和限额似乎是同一个问题，但是具体的场景不同：
限额指的是额度限制，比如是发券、抽奖场景下的重要数据限制。这种限频的要求的宁可不发也不能多发，必须满足百分百的正确性。

结论：限额组件需要保障数据的一致性，一般来说需要落地存储。

典型的限额算法

典型的限额算法有两个窗口算法，两个桶算法

固定窗口

算法过程

在每个时间窗口（如1分钟）设置一个计数和阈值，当该窗口的计数值大于阈值时，则拦截超出阈值的请求，具体见