导读
- 前几天和一个朋友讨论了他们公司的系统问题，传统的单体应用，集群部署，他说近期服务的并发量可能会出现瞬时增加的风险，虽然部署了集群，但是通过压测后发现请求延迟仍然是很大，想问问我有什么改进的地方 。我沉思了一会，现在去改架构显然是不可能的，于是我给出了一个建议，让他去做个接口限流，这样能够保证瞬时并发量飙高也不会出现请求延迟的问题，用户的体验度也会上去 。
- 至于什么是接口限流？怎么实现接口限流？如何实现单机应用的限流？如何实现分布式应用的限流？本篇文章将会详细阐述 。
- 常见的限流算法有很多，但是最常用的算法无非以下四种 。
文章插图
- 固定算法的概念如下
- 将时间划分为多个窗口
- 在每个窗口内每有一次请求就将计数器加一
- 如果计数器超过了限制数量，则本窗口内所有的请求都被丢弃当时间到达下一个窗口时，计数器重置 。
- 固定窗口计数器是最为简单的算法，但这个算法有时会让通过请求量允许为限制的两倍 。考虑如下情况：限制 1 秒内最多通过 5 个请求，在第一个窗口的最后半秒内通过了 5 个请求，第二个窗口的前半秒内又通过了 5 个请求 。这样看来就是在 1 秒内通过了 10 个请求 。
文章插图
滑动窗口计数器
文章插图
- 滑动窗口计数器算法概念如下：
- 将时间划分为多个区间；
- 在每个区间内每有一次请求就将计数器加一维持一个时间窗口，占据多个区间；
- 每经过一个区间的时间，则抛弃最老的一个区间，并纳入最新的一个区间；
- 如果当前窗口内区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃 。
- 滑动窗口计数器是通过将窗口再细分，并且按照时间 " 滑动 "，这种算法避免了固定窗口计数器带来的双倍突发请求，但时间区间的精度越高，算法所需的空间容量就越大 。
文章插图
- 漏桶算法概念如下：
- 将每个请求视作 " 水滴 " 放入 " 漏桶 " 进行存储；
- “漏桶 " 以固定速率向外 " 漏 " 出请求来执行如果 " 漏桶 " 空了则停止 " 漏水”；
- 如果 " 漏桶 " 满了则多余的 " 水滴 " 会被直接丢弃 。
- 漏桶算法多使用队列实现，服务的请求会存到队列中，服务的提供方则按照固定的速率从队列中取出请求并执行，过多的请求则放在队列中排队或直接拒绝 。
- 漏桶算法的缺陷也很明显，当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应 。
文章插图
- 令牌桶算法概念如下：
- 令牌以固定速率生成 。
- 生成的令牌放入令牌桶中存放，如果令牌桶满了则多余的令牌会直接丢弃，当请求到达时，会尝试从令牌桶中取令牌，取到了令牌的请求可以执行 。
- 如果桶空了，那么尝试取令牌的请求会被直接丢弃 。
- 令牌桶算法既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求，因此是目前使用较为广泛的一种限流算法 。
- 在传统的单体应用中限流只需要考虑到多线程即可，使用google开源工具类guava即可 。其中有一个RateLimiter专门实现了单体应用的限流，使用的是令牌桶算法 。
- 单体应用的限流不是本文的重点，官网上现成的API，读者自己去看看即可，这里不再详细解释 。
- 分布式限流和熔断现在有很多的现成的工具，比如Hystrix，Sentinel 等，但是还是有些企业不引用外来类库，因此就需要自己实现 。
- redis作为单线程多路复用的特性，很显然能够胜任这项任务 。
- 使用令牌桶的算法实现，根据前面的介绍，我们了解到令牌桶算法的基础需要两个个变量，分别是桶容量，产生令牌的速率 。
推荐阅读
- Java程序员最常犯的错TOP10，你还在犯么？
- 沩山毛尖是绿茶还是黄茶,沩山毛尖属于绿茶还是黄茶
- 沩山毛尖属于绿茶还是黄茶,沩山毛尖有什么历史渊源
- 罗永浩|交个朋友黄贺回应与罗永浩“分手”：没有矛盾、还会回来直播
- 君山银针是绿茶还是黄茶,什么是黄茶
- 淘宝直播的浮现权是什么意思 淘宝主播没有浮现权了还能直播吗?
- 女性这样做，不仅提前5年退休，还有7000补贴领
- 葡萄酒开瓶塞后喝不完，还能保存多久？听酒厂师傅说完，涨知识了
- 高速公路上错过出口咋办？交警：错过别掉头，这样做省时还不绕路
- 开车撞了人怎样保证自己不会被讹？还能及时救治伤者，记住这6点
