如果你写一个 bug 管理系统,用了这个
PeriodLimit
你就可以限制每个测试人员每天只能给你提一个 bug。工作是不是就轻松很多了?:P
如今微服务架构大行其道本质原因是因为要降低系统的整体复杂度,将系统风险均摊到子系统从而最大化保证系统的稳定性,通过领域划分拆成不同的子系统后各个子系统能独立的开发、测试、发布,研发节奏和效率能明显提高。
但同时也带来了问题,比如:调用链路过长,部署架构复杂度提升,各种中间件需要支持分布式场景。为了确保微服务的正常运行,服务治理就不可或缺了,通常包括:限流,降级,熔断。
其中限流指的是针对接口调用频率进行限制,以免超出承载上限拖垮系统。比如:
-
电商秒杀场景
-
API 针对不同商户限流
常用的限流算法有:
-
固定时间窗口限流
-
滑动时间窗口限流
-
漏桶限流
-
令牌桶限流
本文主要讲解固定时间窗口限流算法,主要的使用场景比如:
-
每个手机号每天只能发5条验证码短信
-
每个用户每小时只能连续尝试3次密码
-
每个会员每天只能领3次福利
工作原理
从某个时间点开始每次请求过来请求数+1,同时判断当前时间窗口内请求数是否超过限制,超过限制则拒绝该请求,然后下个时间窗口开始时计数器清零等待请求。