流量限制方法和系统的制作方法
【技术领域】
[0001]本发明涉及应用服务技术领域，特别是涉及一种流量限制方法和系统。
【背景技术】
[0002]随着互联网的发展，WEB(互联网)服务器承担着越来越大的请求量。WEB服务器的稳定性是提供可靠服务的基本保证。对WEB服务器实施流量限制可以有效地保护WEB服务器，保证服务器不会过载，从而提高服务质量，增强服务提供者的竞争力。
[0003]目前的限流技术一般采用速率限制，直接采用漏桶算法或者令牌桶算法(Tokenbucket)来实现流量限制。令牌桶算法是一种经典的网络流量整形和流量限制算法，可以平滑网络流量同时又允许一定程度的突发流量。令牌桶算法通常以恒定速率向大小固定的令牌桶注入令牌，以达到防止网络拥塞的目的。其中一个典型的实现是Google Guava的RateLimiter (速率限制器)。在实现过程中，发明人发现传统技术中至少存在如下问题:
[0004]以速率作为流量限制有一个隐藏的前提是后台服务能够在限定的时间内完成请求，才可以用固定的速率来放行请求。当后端响应延迟变大的时候，请求被堆积在WEB服务器中，此时收到的请求速率并没有变化。但由于WEB服务器的内存等资源被堆积的请求占用不能释放，一方面会消耗大量的内存和线程资源，另一方面WEB服务器的接受请求的速率会变慢。而类似RateLimiter的技术方案并不能有效的缓解WEB服务器的压力。
【发明内容】
[0005]基于此，有必要针对保障WEB服务器稳定运行的问题，提供一种流量限制方法和系统。
[0006]为了实现上述目的，本发明技术方案的实施例为:
[0007]—方面，提供了一种流量限制方法，包括以下步骤:
[0008]根据匹配规则将请求与配置给当前后台服务的令牌桶进行匹配；
[0009]若匹配成功，基于该请求向该令牌桶申请令牌；
[0010]若匹配失败，返回空值，并判断配置给各后台服务的令牌桶是否均已匹配完毕；
[0011]若未匹配完毕，将下一个配置有令牌桶的后台服务作为当前后台服务，返回根据匹配规则将请求与配置给当前后台服务的令牌桶进行匹配的步骤；
[0012]若匹配完毕，反馈匹配失败信号。
[0013]另一方面，提供了一种流量限制系统，包括连接WEB服务器的匹配单元；
[0014]匹配单元用于根据匹配规则将请求与配置给当前后台服务的令牌桶进行匹配；并在匹配成功时，基于该请求向该令牌桶申请令牌；
[0015]匹配单元还用于在匹配失败时，返回空值，并判断配置给各后台服务的令牌桶是否均已匹配完毕:在判断未匹配完毕时，将下一个配置有令牌桶的后台服务作为当前后台服务，并根据匹配规则将请求与配置给当前后台服务的令牌桶进行匹配；在判断匹配完毕时，反馈匹配失败信号。
[0016]上述技术方案具有如下有益效果:
[0017]因为本发明的流量限制方法和系统对令牌桶算法进行了改造，对应每一种不可靠的后台服务配置令牌桶，所以不同于传统令牌桶算法，本发明中的令牌不以恒定速率注入，而是由令牌桶自己归还，克服了 WEB服务器接受请求的速率变慢的问题，进而使本发明的流量限制方法和系统能够通过多令牌桶隔离不可靠的后台服务，在后端响应时间不确定的情况下，保障WEB服务器的稳定运行，堆积的请求不会令服务器出现挂死或者宕机的现象，从而更好的控制WEB服务器的并发请求数，使得服务器更加稳定可靠。
【附图说明】
[0018]通过附图中所示的本发明的优选实施例的更具体说明，本发明的上述及其它目的、特征和优势将变得更加清晰。在全部附图中相同的附图标记指示相同的部分，且并未刻意按实际尺寸等比例缩放绘制附图，重点在于示出本发明的主旨。
[0019]图1为本发明流量限制方法和系统一应用场景图；
[0020]图2为本发明流量限制方法和系统的运行示意图；
[0021]图3为本发明流量限制方法实施例1的流程示意图；
[0022]图4为本发明流量限制方法实施例1中请求与令牌桶进行匹配步骤的流程示意图；
[0023]图5为本发明流量限制方法实施例1中基于请求向匹配成功的令牌桶申请令牌的流程示意图；
[0024]图6为本发明流量限制方法实施例2的流程示意图；
[0025]图7为本发明流量限制系统实施例1的系统结构示意图；
[0026]图8为本发明流量限制系统实施例1中匹配单元的系统结构示意图；
[0027]图9为本发明流量限制系统实施例1中基于请求向匹配成功的令牌桶申请令牌的系统结构示意图。
【具体实施方式】
[0028]为了便于理解本发明，下面将参照相关附图对本发明进行更全面的描述。附图中给出了本发明的首选实施例。但是，本发明可以以许多不同的形式来实现，并不限于本文所描述的实施例。相反地，提供这些实施例的目的是使对本发明的公开内容更加透彻全面。
[0029]除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。
[0030]图1为本发明流量限制方法和系统的应用场景图。
[0031]如图1所示，WEB服务器根据不同的请求需要访问不同的后台服务。这些后台服务可能是内部提供的服务，也可能是第三方提供的服务。当某些服务不能保证响应时延的时候，请求会被堆积在WEB服务器内部。
[0032]假设WEB服务器每秒收到200个请求，其中100个请求属于后台服务_1。如果后台服务-1的响应变得很缓慢，假设30秒才能够返回结果，那么就会有大约3000个关于后台服务-1的请求同时堆积在WEB服务器中。如果WEB服务器的并发数小于3000，持续的压力就有可能导致服务器出现各种问题，最后出现挂死或者宕机现象。即使WEB服务器的容量大于3000，大量堆积的关于后台服务-1的请求占据了服务器的资源，其他服务的请求得不到响应，对服务器的吞吐量也会造成巨大的影响。
[0033]而传统技术中的RateLimiter不能有效的解决上述场景所出现的问题。当请求被堆积在WEB服务器的时候，收到的请求速率并没有变化。相反由于WEB服务器的内存等资源被堆积的请求占用不能释放，WEB服务器的接受请求的速率会变慢。因此，我们需要一种更有效的方法和系统来保护WEB服务器。
[0034]为了保障WEB服务器的稳定运行，本发明提供了一种流量限制方法和系统，图2为本发明流量限制方法和系统的运行示意图；
[0035]本发明基于改造的令牌桶算法提出了一种多令牌桶的解决方案，具体如图2所示，每个令牌桶对应着一种不可靠的后台服务。根据实际的请求情况设置每个令牌桶的容量，使所有令牌桶的总容量不大于WEB服务器容量。其中，不可靠的后台服务一般是第三方平台提供的接口或者内部新开发的服务器，例如各省的彩铃平台或短信平台等，一般无法控制这种服务平台的响应时间，或者要求这种第三方平台去优化系统，使得响应内部请求的时间达到要求，即不能保证响应时延的后台服务，因此在实际应用中，需要为WEB服务器系统提供保护措施。
[0036]在一个具体的实施例中，可以针对一段时间内的在线系统外部请求数量做统计，并以此为依据估算系统的令牌桶容量。而根据在线系统的数据做出统计得到的令牌桶容量，这个容量一旦设定一般不对其做更改。一般而言，WEB服务器系统的请求量会在某个范围内波动，因此在设置令牌桶容量的容量后，也无须进行更改。
[0037]基于以上内容，本发明提供了一种流量限制方法实施例1，具体如下所述:
[0038]本发明基于改造的令牌桶算法提出了一种多令牌