[发明专利]基于服务接口的限流方法、装置、电子设备及存储介质

说明书

本申请涉及一种基于服务接口的限流方法、装置、电子设备及存储介质，该方法包括：确定待调用接口在滑动时间窗口内的调用阈值；根据当前时间戳以及所述滑动时间窗口确定第一时间区间；统计所述第一时间区间内所述待调用接口的第一调用次数；当所述第一调用次数大于所述调用阈值时，执行限流操作。该技术方案通过采用滑动时间窗口的设计，不仅实现了两个相邻时间段内接口的调用次数与不会超过预设的调用阈值，而且两个时间段内的任一时间区间的调用次数也不会超过预设的调用阈值，从而达到平滑限流。另外，本申请提供的限流方法还可以应对突发流量，并且进行精准的限流。

技术领域

本申请涉及互联网技术领域，尤其涉及一种基于服务接口的限流、装置、电子设备及存储介质。

背景技术

在日常生活中经常会出现突发的高并发场景，诸如：在购物狂欢节期间一些热门商品的降价促销，导致平台的服务接口被几十万、上百万甚至上千万次访问，会形成一个较大的流量，这种情况下每一次查询库存请求都集中到数据库，导致效率低。在实现本发明的过程中，发明人发现，目前的限流措施并不能进行平滑的限流，并会产生突刺现象，从而造成网络拥堵，导致用户体验低。以下为目前限流措施存在的缺陷：

计数器限流法存在的缺陷：

计数器限流一般会通过控制一秒钟能够通过的请求数，比如qps为1000，算法的实现思路就是从第一个请求进来开始计数，在下来的一秒钟内，每过来一个请求，就把计数器的值加1，如果累加数字达到了1000，那么后续的请求将会被拒绝。等到一秒钟结束后，把计数器的值恢复为0，重新开始计数。这种算法的缺点是，如果在单位时间一秒内的前10ms，请求了1000次，那么后面的990ms内的请求将会被拒绝，会产生“突刺现象”，不能进行平滑的限流。

漏桶限流法存在的缺陷：

漏桶(Leaky Bucket)算法实现思路,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。因为漏桶一直以一定的速度出水，所以无法应对短时间的突发流量。

令牌桶限流法存在的缺陷：

令牌桶算法(Token Bucket)和Leaky Bucket效果一样但方向相反的算法,更加容易理解。随着时间流逝，系统会按恒定1/QPS时间间隔(如果QPS＝1000,则间隔是1ms)往桶里加入Token，如果桶已经满了就不再加了。新请求来临时,会各自取走一个Token,如果没有Token可取就阻塞或者拒绝服务。令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。Google guava提供的工具库中的Rate Limit就是基于令牌桶算法实现的，但是这仅限制在单节点，如果是分布式系统，每个节点的QPS是一样的，请求量到服务接口那的话就是QPS*节点数了。所以这种方案在分布式的情况下不适用。

基于Redis的String数据结构的限流方案存在的缺陷：

可以使用接口名来作为key，初始值为1，通过设置其过期时间来进行限流；即(setex(key,expire time,1))当每次访问时如果存在该key，就将值加1；(即incr(key))如果不存在，设置默认值为1即可；(即setex(key,expire time,1))这种方法虽然解决了分布式下的限流问题，但是在一段时间内进行限流，这样存在两个时间段分别不超过阈值，但是可能存在两个时间段之间的时间段超过阈值的情况，不能进行精准的限流。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请提供了一种基于服务接口的限流方法、装置、电子设备及存储介质。

第一方面，本申请提供了基于服务接口的限流方法，包括：