CN113485831A - 一种业务限流方法、计算设备及存储介质 - Google Patents

Abstract

本申请提供了一种业务限流方法、计算设备及存储介质。其中所述方法包括：获得服务请求；获得所述服务请求中携带的特定标识；周期性的对所述服务请求进行计数，若在任一周期内获得所述特定标识的服务请求的数量达到预设阈值，则不处理所述任一周期内新接收到的携带所述特定标识的服务请求。采用本申请的基于业务类型的业务间隔离限流方法，能够有针对性的对大流量业务进行限流，或者即使在某一业务流量突增的情况下，也不会影响其他业务线的服务请求的正常处理。

Description

一种业务限流方法、计算设备及存储介质

技术领域

本申请涉及数据通信领域，尤其涉及一种业务限流方法、计算设备及存储介质。

背景技术

服务限流是指当系统资源不够，不足以应对大量请求，为了保证有限的资源能够正常服务，对系统按照预设的规则进行流量限制或功能限制的一种方法。从而起保护服务节点或者集群后面的数据节点，防止瞬时流量过大使服务和数据崩溃(如前端缓存大量实效)，造成不可用。

现有技术在服务限流方面已经具有一些解决方案。例如较简单的策略是随机选择一些请求进行响应，另外一部分请求被过滤或拒绝。然而，这种限流方案虽然从数据处理的角度看似解决了瞬时流量过大的问题，但在某些行业应用中这种随机的策略并不能达到期望的效果。

发明内容

本申请提供一种服务限流方法。获得服务请求；获得所述服务请求中携带的特定标识；周期性的对所述服务请求进行计数，若在任一周期内获得所述特定标识的服务请求的数量达到预设阈值，则不处理所述任一周期内新接收到的携带所述特定标识的服务请求。

上述方法中，若在任一周期内获得相同特定标识的服务请求数量达到预置的阈值，所述方法还包括：向服务请求的发起端反馈拒绝处理该服务请求的通知消息。

上述方法中，所述特定标识包括业务类型标识；以及，按照第一时长周期性的对所获得的服务请求进行计数，若在任一周期内获得相同业务类型标识的服务请求的数量达到第一阈值，则不处理所述任一周期内新接收到的携带所述业务类型标识的服务请求。

上述方法基础上，所述特定标识包括商品标识；以及，按照第二时长周期性的对所获得的服务请求进行计数，若在所述任一周期内获得所述商品标识的服务请求的数量达到第二阈值；则不处理所述任一周期内新接收到的携带所述商品标识的服务请求。

其中，所述第一时长与第二时长相同或者不同。

所述方法还包括：对不进行处理的服务请求进行缓存；以及，在所述任一周期的下一个周期，所述业务服务器获得服务请求还包括获得已缓存的服务请求。

一种集群系统业务限流系统，包括：

主控服务器和多个业务服务器；

业务服务器，获得服务请求，和所述服务请求携带的特定标识；

所述主控服务器，周期性的对所述多个业务服务器所获得的服务请求进行计数，若在任一周期内获得相同所述特定标识的服务请求数量达到预置的集群阈值，则控制所述多个业务服务器不处理所述任一周期内新接收到的携带所述相同特定标识的服务请求。

上述系统中，所述主控服务器控制所述多个业务服务器不处理所述任一周期内新接收到的携带该特定标识的服务请求，包括：

业务服务器，获得服务请求后，向主控服务器发送上报消息，携带所述特定标识；

主控服务器，若在所述任一周期内上报的获得相同所述特定标识的服务请求数量达到预置的集群阈值，则通知该业务服务器对所述服务请求不进行处理，否则通知该业务服务器对所述服务请求进行处理。

上述系统基础上，业务服务器，还周期性的根据服务请求携带的特定标识对接收到的服务请求进行计数；以及，业务服务器向主控服务器发送上报请求后，若在预置的时间内未收到主控服务器下发的对所述服务请求是否处理的通知，并且，该业务服务器在所述任一周期内接收到的与当前服务请求携带的特定标识相同的服务请求数量达到预置的单机阈值，则对所述服务请求不进行处理。

上述系统中，所述特定标识包括业务类型标识；

主控服务器，按照第一时长周期性的对所获得的服务请求进行计数，若在任一第一时长周期内获得相同业务类型标识的服务请求数量达到第一集群阈值，则通知该业务服务器对所述服务请求不进行处理。

或/和，所述特定标识包括商品标识；

主控服务器，按照第二时长周期性的对所获得的服务请求进行计数，若在任一第二时长周期内获得相同商品标识的服务请求数量达到第二集群阈值，则不处理所述任一第二时长周期内新接收到的携带该业务类型标识的服务请求。

其中，所述第一时长与第二时长相同或者不同。

上述系统中，所述主控服务器控制所述多个业务服务器不处理所述任一周期内新接收到的携带该特定标识的服务请求，包括：

业务服务器，若在所述任一周期内，未收到来自主控服务器的对所述特定标识的服务请求不进行处理的通知消息，则向主控服务器发送上报消息，携带所述特定标识，对该服务请求进行处理；否则，不对该服务请求处理；

主控服务器，若在所述任一周期内上报的获得相同所述特定标识的服务请求数量达到预置的阈值，则通知集群的所有业务服务器，在所述任一周期内对携带该特定标识的服务请求不进行处理。

以及，在以上系统中，业务服务器，若对服务请求不进行处理，还进一步向所述服务请求的发起端反馈拒绝处理所述服务请求的通知消息。

进一步的，业务服务器，还包括对所述任一周期内不进行处理的服务请求进行缓存；以及在所述任一周期的下一个周期，所述业务服务器获得服务请求还包括获得已缓存的服务请求。

一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如上所述的方法。

一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器执行如上所述的方法。

本申请提供了一种业务限流的方法。在一个周期内，对携带不同业务类型标识的服务请求分别进行计数。如果周期内来自某个业务(业务类型标识进行区分)的服务请求达到预置的阈值，则在该周期内如果接收到该业务类型的新的服务请求，则不再根据新的服务请求对数据库进行操作，即不处理新的服务请求。采用本申请的基于业务类型的业务间隔离限流方法，能够有针对性的对大流量业务进行限流，或者即使在某一业务流量突增的情况下，也不会影响其他业务线的服务请求的正常处理。

并且，本申请还提供了一种针对热门商品的限流方法，根据服务请求中携带的商品标识，分别对周期内获取到的不同商品的服务请求进行计数。当当某个商品标识的服务请求在周期内达到预设的阈值时，则对该周期内新接收到的该商品的服务请求不进行处理。从而，当某一商品订单流量突增的情况下，也不会影响其他商品订单的服务请求的正常处理。

并且，本申请方法还可以对集群服务器进行业务限流。本申请中，集群业务器与主控服务器保持通信，将各自接收到服务请求的情况上报给主控服务器，主控服务器根据对集群内所有服务器所述任一周期获得服务请求的总体数量，控制业务服务器是否对所述任一周期内获得的该服务请求进行处理。采用本方法，主控服务器根据集群服务器整体接收到服务请求的情况做出是否限流的决策，因而，由于限流决策由主控服务器做出，避免了集群服务器中由于单个服务器接收到的服务请求达到限流标准从而使得集群中其他服务器也停止服务请求的处理。

进一步的，考虑到网络通信的不稳定，单机服务器在无法取得与主控服务器无法取得通信的情况下，还可以切换执行本地单机限流策略。更加适用于复杂网络环境。

以及，本申请的业务限流还采用了预热的手段，从而使得在任何时候都可以对服务请求的突发快速做出响应。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1为本申请实施例应用场景示意图；

图2为本申请一方法实施例流程示意图。

具体实施方式

下面将参照附图更详细地描述本申请的优选实施方式。虽然附图中显示了本申请的优选实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

参照图1所示的本申请实施例的应用场景，订单中心接入了多个业务线，例如图中所示的A类业务课程、B类业务课程、金币商城等。图1仅是示例性的展示了3个业务线。

订单中心接到订单请求后，查询该订单中商品的信息，例如价格等。假设订单中心接收到来自B类业务课程业务线的某个订单，该订单中用户对三个商品进行了下单操作，例如订单中的商品包括：B类业务英语1阶段课程、B类业务音乐1阶段课程以及B类业务美术1阶段课程。订单中心查询所述三个订单课程的商品信息，例如课程编码、课程价格等。

订单中心通知商品库存中心对数据库进行商品数量的变更操作。对商品的库存记录做变更操作。

假设数据库中保存的课程库存数据分别为：B类业务英语1阶段课程库存数量为1000、B类业务音乐1阶段课程库存数量为790、B类业务美术1阶段课程库存数量为1200。则数据库将B类业务英语1阶段课程库存数量由1000更新为999。同样，分别对B类业务音乐1阶段课程库存数量以及B类业务美术1阶段课程库存数量做减1操作。

随着业务的发展，订单交易的服务请求量越来越大，订单中心和商品库存中心的压力越来越大。商品库存中心需要对数据库中相关记录反复进行读写更新操作，尤其是在某业务领域中特定商品进行集中大量下单时，数据库对该商品条目的读写更新操作将十分频繁且集中，所以保障系统订单交易的稳定十分重要。

本申请提供了一种业务限流的方法。参照图1所示，该方法包括：

11)获得服务请求。

所述服务请求包括，当用户对某商品下单时，系统接收到的订单请求。

12)获得服务请求中携带的特定标识，例如业务类型标识。用户服务请求中包含多个字段，其中包括了该服务请求所属业务类型的标识。

以订单请求为例，订单请求中携带不同业务接口的业务类型标识，不同的业务接口标识对应于业务线，因而根据该业务类型标识可以确定该订单请求所属的业务线。从订单请求中获得该业务类型标识，用于区分订单所属的业务类型。

13)周期性的对所获得的服务请求按照业务类型标识分别进行计数，若在任一周期内获得相同所述特定标识的服务请求数量达到预置的第一阈值，则不处理所述任一周期内新接收到的携带该特定标识的服务请求。

按照一定的周期，循环的统计一个周期内，对接收到的属于不同业务类型的订单请求进行数量统计。如果在一个周期内，已经接收到的某个业务类型的订单请求数量达到了一定阈值，则对于该周期内再接收到的订单请求不再进行处理，例如，不对商品库存数据库进行数量更新等读写操作。

采用以上方法，当多个用户或者一个用户，分别在A类业务课程、B类业务课程、金币商城进行下单操作。则系统获得了分别来自A类业务课程、B类业务课程、金币商城的三个业务线的多个订单请求。例如用户甲下单了B类业务课程产生了订单请求A，用户乙在用户甲之后下单了A类业务课程产生了订单请求B，以及下单了B类业务课程产生了订单请求C，用户丙在用户乙之后下单了金币商城中的某个礼品，产生了订单请求D。

系统获得订单请求，从订单请求中获得携带的业务类型标识，假设A类业务课程的订单中业务类型标识为100，B类业务课程业务类型标识为101，金币商城业务类型标识为102。

周期性的，分别对接收到的具有相同业务类型标识的订单请求进行计数。例如，以1秒为周期，分别统计在一秒中内接收到的各业务类型的订单请求数量，并判断该周期内，获得的某个类型的订单请求是否超过了预置的第一阈值，如果是，则不处理该周期内新接收到的该业务类型的业务请求。

假设在某一个周期内，系统已经获得了业务类型标识100的订单请求345个，获得业务类型标识为101的订单请求数量为399个，获得业务类型标识为102的订单请求数量为388个。并且，在该周期内进一步又获得了上述用户甲、乙、丙的4个订单请求。如果上述第一阈值设置为400，则按照本申请的方法，系统将进行如下处理。

获得用户甲的订单请求A，获得业务类型标识为101。现有业务类型标识为101的订单请求计数值为399，未达到400的第一阈值。则对现有业务类型标识为101的订单请求数399加1得到400。并且根据订单请求A对数据库中的B类业务相应课程库存数量进行读写的更新操作。

获得用户乙的订单请求B和订单请求C。订单请求B中携带业务类型标识100。现有业务类型标识为100的订单请求计数值为345，未达到第一阈值400。则系统将现有业务类型标识为100的订单请求数345增加1得到346。并且，进一步根据订单请求B对数据库中的A类业务相应课程库存数量进行读写的更新操作。具体的，将数据库中库存的A类业务相应课程的数量减1操作，例如将剩余课程数20减1后得到19。

订单请求C中携带业务类型标识101。系统在获得订单请求A后，当前周期内业务类型标识为101的订单请求计数值达到400的第一阈值。因而，不根据该订单请求C对数据库进行读写操作，则用户乙的订单请求C未成功被系统响应处理。

进一步的，如果系统判断不依据订单请求C对数据库的商品库存数量进行更新操作，则系统还可能做出其他操作，例如：向订单请求C的发起端返回拒绝处理订单请求C的通知消息；也或者/和将订单请求C进行缓存，待下一个周期开始时，按照已缓存订单请求的顺序读取订单请求，并按照上述方法在所述下一个周期内判断是否对订单请求进行处理，即依据订单请求对数据库中的某条记录进行读写操作。

订单请求D中携带业务类型标识102。现有业务类型标识为102的订单请求计数值为388，未达到第一阈值400。则系统将现有业务类型标识为102的订单请求数388增加1得到389。并且，进一步根据订单请求C对数据库中的金币商城中的相应商品库存数量进行读写的更新操作，具体的将库存数量进行减1的操作。

以上实施例中，由于1秒的周期内，获得B类业务线的订单请求达到了预设的第一阈值400，表明该周期内系统对数据库B类业务相关的数据记录读写操作十分频繁，为了减小数据库的操作压力，因而在该周期内对B类业务线的订单请求进行限流，暂停对数据库中B类业务相关记录的更新操作。同时，并不停止A类业务线和金币商城的订单请求的处理响应，依然根据订单请求对数据库中A类业务线和金币商城相关库存数据进行更新操作。

与现有技术相比，以上实施例中在系统接入多个业务方的场景下，基于业务身份进行精细化限流。基于业务身份，各个业务线之间创建订单的流量实现隔离限流，即使某一业务的流量突增，也不会影响对其他服务请求的处理。例如，系统分别获得A类业务课程、B类业务课程、C类业务三个业务线的用户下单请求。并且在某个时段，例如促销期间，A类业务课程的订单量突增。采用本申请的方法，在A类业务的周期内订单量达到阈值时，对新接收到的A类业务课程的服务请求不进行处理，但可以继续对其他业务线的服务请求(例如B类业务课程、C类业务等)做出响应，根据所述其他业务线的服务请求对数据库进行操作。可见，采用本申请的方法，可以有针对性行的对服务请求进行限流，与现有的方法相比，不会由于某一个业务线的服务请求突增而影响对其他业务线服务请求的响应。

现有技术中，存在部分业务的商品被抢购的场景。例如在线教育产品的金币商城中的某些商品是热门商品，受到用户的喜爱，用户集中对这些热门商品下单，意味着同一个库存记录，商品库存中心可能接收好多个变更操作请求，商品库存中心会对数据库中该热门商品的记录进行集中大量的变更操作，数据库的每秒查询率(QPS)将出现较大峰值。热门商品的服务请求是对数据库存储的库存表中该热门商品这一条例库存记录进行频繁更新，因而对数据库造成的压力较大，同时也会影响数据表的相关服务。

本申请又一实施例实现根据服务请求中携带的商品标识对服务请求进行限流的方法。

该方法包括：

21)获得服务请求。

所述服务请求包括，当用户对某商品下单时，系统接收到的订单请求。

22)获得服务请求中携带的商品标识。

用户服务请求中包含多个字段，其中包括该服务请求对应的商品标识。

以订单请求为例，订单请求中不仅携带不同业务接口的业务类型标识，还携带商品标识。例如B类业务中包含了多个商品，如英语、思维、阅读、美术等，并且每个学科还进一步按照学习阶段划分为多个商品，每个商品都有相应的商品标识；

13)周期性的对所获得的服务请求按照商品标识分别进行计数，若在任一周期内获得相同所述商品标识的服务请求数量达到预置的第二阈值，则不处理所述任一周期内新接收到的携带该特定标识的服务请求。

本申请中，可以单独依据业务类型标识对服务请求进行限流，也可以单独依据商品标识对热门商品服务请求进行限流。

在优选实施例中，系统可以同时采用两种限流策略，既依据业务类型标识对服务请求进行限流，也依据商品标识对热门商品服务请求进行限流。

此时，按照商品标识对服务请求分类计数的周期(下称第二时长周期)可以与按照业务类型标识对服务请求分类计数的周期(下称第一时长周期)时长可以相同，也可以不同。例如，二者均以时长为1秒为单位周期性的进行技术。或者以1秒周期性的按照业务类型标识对服务请求分类计数，并且按照2秒周期性的按照商品标识对服务请求分类计数。本申请并不对周期的具体取值进行限定，上述1秒或者2秒仅为举例。

并且，当第一时长与第二时长相同时，优选实现方式是第一时长周期与第二时长周期起始点时刻相同，即第一时长周期与第二时长周期相同。作为其他实现方式，在第一时长与第二时长相同的情况下，第一时长周期与第二时长周期的起始时刻也可以不同。例如第一时长和第二时长均为1秒时，第二时长周期相比第一时长周期延后半秒。

以及，上述实施例的第二阈值可以与上述第一阈值相同，也可以不同。

作为较佳的实现方式，当第一时长与第二时长相同时，所述第一阈值大于所述第二阈值。

本申请实施例采用的限流策略可以实时自主的限制商品的突发服务请求，因而不仅实现了对热门商品的业务限流，保证其他商品的服务请求的正常响应。并且，无需提前定义哪些商品属于热门商品，因而适用性更强，具有更好的可靠性，适合互联网业务快速变化的需要。

以上实施例的业务限流策略，包括按照业务标识根据业务身份进行限流的策略，以及按照商品标识按照商品进行限流的策略。所述两个策略可以单独实施，具有各自的效果，达到按照业务身份限流或者对热门商品限流的目的；也可以同时采用两个策略，既达到按照业务身份限流的目的也达到对热门商品限流的目的。

以上限流策略可以在单台服务器上实现服务限流，也可以应用于多台服务器组成的集群服务器。

在集群服务器场景下，可以针对集群中的每台服务器实施以上限流策略。例如，对于每台服务器按照业务身份进行限流，服务请求响应的阈值均设置为500。假设集群中第一台服务器获得的某类服务请求达到该阈值，则会向请求端返回拒绝的消息。然而，集群服务器中其他服务器获得的该类服务请求未达到阈值，可以响应该类服务请求并对库存商品数量进行更新。但服务请求发起端已经收到了所述第一台服务器返回的拒绝消息，从而结束该条服务。因此，对于集群系统而言，对每台服务器设置限流策略，有可能出现某个服务器因达到流量最大值导致集群系统拒绝该类服务请求而导致用户端发起的服务请求结束的情况，使本应该被处理的用户请求无法成功处理，从而造成了业务损失。

具体举例，假设一个包含10台能力相同的业务服务器的服务器集群，集群的总体阈值是5000，每台服务器设置的阈值为500。当周期内某一台服务器接收的某类服务请求达到500时，这台服务器接收的后续服务请求都会被拒绝处理，这部分被拒绝处理的请求则会造成业务损失，因为目前集群内服务器的总体请求数还没有达到5000。这部分被拒绝的请求是在承载能力范围内可以处理的。

因而，在集群服务器场景下，较佳的实现方式是对集群服务器进行整体限流。集群整体限流是基于周期内集群服务器整体接收到的服务请求量做出是否拒绝新服务请求的决策。不会出现由于单台服务器收到的服务请求达到上限时直接拒绝用户端的服务请求，而是基于集群服务器整体处理能力做出是否业务限流的判断。因而集群限流与对集群中每台服务器限流相比不会造成集群服务器资源的浪费，且不会出现频繁拒绝新服务请求的问题。

以下实施例说明上述限流策略在集群服务器上的实现方法。

本实施例以按照业务类型标识对订单请求进行限流策略为例进行说明。一种集群系统业务限流系统，其特征在于，包括：主控服务器和多个业务服务器。

业务服务器，获得服务请求，业务服务器通过解析订单请求，获得订单请求中携带的业务类型标识。

例如，用户对B类业务课程业务中的某个课程进行下单，业务服务器从该用户端发送的订单请求中获得业务类型标识为101。

业务服务器向主控服务器报告收到一个业务类型标识为101的订单请求。若该业务服务器收到一个业务类型标识为100的订单请求，则向主控服务器进行上报。

类似的，集群中的所有业务服务器在收到一个订单请求后，均解析得到该订单请求中的业务类型标识，并向主控服务报告收到订单请求以及该订单请求的业务类型标识。并且在未得到主控服务器返回的控制消息前不对接收到的订单请求进行处理。

主控服务器，获得业务服务器上报的消息，周期性的对所述多个业务服务器所获得的服务请求按照业务类型标识进行计数。若在任一周期内获得相同业务类型标识的订单请求数量达到预置的集群阈值，则控制所述多个业务服务器不处理所述任一周期内新接收到的携带与达到阈值的业务类型标识相同的订单请求。

举例假设，主控服务器分别获得来自集群中三个业务服务器上报的消息，分别为业务服务器A接收到业务类型标识为100的订单请求和101的订单请求；业务服务器B接收到业务类型标识为100的订单请求和102的订单请求；业务服务器C接收到业务类型标识为100的订单请求和101的订单请求；

假设主控服务器在某一个计数周期内，先后获得业务服务器A\业务服务器B和业务服务器C的上报消息。并且，在该周期内，主控服务器已经收到集群服务器上报的业务类型标识为100的订单请求共计398个，业务类型标识为101的订单请求共计366个，业务类型标识为102的订单请求共计399个。假设集群阈值设为400。

主控服务器接收到业务服务器A的上报消息后，判断业务类型标识为100的订单请求和101的订单请求均未达到400的阈值，因而，分别将所述周期内业务类型标识为100的订单请求的总数和101的订单请求的总数加1，得到业务类型标识为100的订单请求数为399，业务类型标识为101的订单请求数为367。并且，主控服务器向业务服务器A返回通知消息，通知业务服务器A对接收到的类型标识为100的订单请求和101的订单请求进行处理，即基于所述两个订单请求对数据库中的商品库存信息进行更新操作。

主控服务器接收到业务服务器B的上报消息后，查找业务类型标识为100的订单请求数为399，业务类型标识为102的订单请求数为399，均未达到400的阈值。因此，分别将业务类型标识为100的订单请求数和102的订单请求数加1，分别得到400。并通知业务服务器B对接收到的类型标识为100的订单请求和102的订单请求进行处理，

主控服务器接收到业务服务器C的上报获得业务类型标识为100的订单请求的消息。发现业务类型标识为100的订单请求数达到400的集群阈值，则通知业务服务器C不对该订单请求进行处理。业务服务器C接收到主控服务器的通知消息，不对接收到的该业务类型标识为100的订单请求进行处理。

以及按照上文记载的方法，业务服务器C还向该业务类型标识为100的订单请求的发起端发送拒绝处理的通知消息；或者将该订单请求进行缓存，在下一个周期按照已缓存订单请求的顺序读取订单请求，并向主控服务器报告。主控服务器按照与本周期相同的策略通知业务服务器C是否处理该订单请求。

主控服务器接收到业务服务器C的上报获得业务类型标识为101的订单请求的消息。该周期主控服务器对业务类型标识为101的订单请求数的统计为367。因此，对业务类型标识为101的订单请求数加1后，通知业务服务器C对接收到的该业务类型标识为101的订单请求进行处理。

上述实施例中，为了方便说明系统的实现方法，主控服务器先后收到了来自业务服务器A、业务服务器B、业务服务器C的上报消息。实际情况中，业务服务器在接收到订单请求后即向主控服务器进行上报，主控服务器按照接收到的上报消息的顺序对是否对相应订单请求进行处理做出判断，并反馈给相应的业务服务器。

以上为按照业务类型标识对订单请求进行限流策略在集群服务器的实现为例，对业务服务器与主控服务器协作实现限流策略的过程进行了说明。同理，采用相同的协作方法可以实现集群基于商品标识对热门商品进行限流。以及集群可以同时采用两种限流策略，此处不再具体赘述。

参见上文，集群对商品限流以及业务限流时采用的统计周期的设置，以及阈值的设置可参见上文的记载。

在上述实施例基础上，考虑到网络通信的不稳定导致业务服务器与主控服务器之间的通信可能受到影响。

因此，本申请在以上实施例基础上，不仅在主控服务器上进行了限流策略的设置，还在各业务服务器上进行了限流策略的设置。并且，各业务服务器按照本地设置的限流策略，也周期性的按照商品标识或/和业务类型标识对本业务服务器接收到的订单请求进行计数。

从而，如果业务服务器将接收到订单请求的消息向主控服务器发出之后，如果在预置的时长内没有收到来自主控服务器的通知消息时，则按照本地的限流策略，判断是否需要对当前收到的订单请求进行限流处理。

这种方法使得由于网络通信故障等情况下，业务服务器无法及时得到主控服务器的指示的情况下能够按照本地限流策略决定是否对接收到的业务请求进行处理或者拒绝处理。

本实施例中，设置在主控服务器的限流策略采用的阈值与设置在各业务服务器的限流策略采用的阈值可以不同，例如，对于业务类型标识的订单请求，主控服务器设置阈值为500，各业务服务器设置的阈值为100。同理商品标识订单请求限流阈值也可以设置为不同。所述500和100仅是举例，并非是实现本申请的限制。

本申请提供另一个实施例实现集群限流。该方法为：

主控服务器，若在任一周期内上报的获得相同所述特定标识的服务请求数量达到预置的阈值，则通知集群的所有业务服务器，在所述任一周期内对携带该特定标识的服务请求不进行处理。

业务服务器，若在所述任一周期内，未收到来自主控服务器的对该特定标识的服务请求不进行处理的通知消息，则向主控服务器发送上报消息，携带所述特定标识，对该服务请求进行处理；否则，不对该服务请求处理。

本实施例与上文实施例不同，主控服务器不对各服务器的上报消息进行一一的通知回复，用于指示业务服务器是否应当对相应的订单请求进行处理。本实施例中，主控服务器根据各业务服务器上报的消息，如果判断周期内需要对某个业务类型标识或商品标识的订单请求进行限流，即集群不对本周期内新接收到的订单请求进行处理，则将该消息广播到所有业务服务器。

业务服务器在收到新的订单请求后，解析得到该订单请求中的业务类型标识或/和商品标识，并判断是否接收过主控服务器下发的对该业务类型标识或商品标识不进行处理的通知消息，如果没有，则对该订单请求进行处理，并向主控服务器报告接收到该订单请求及其业务类型标识和/或商品标识。如果主控服务器下发过对该业务类型标识或商品标识进行限流的通知消息，则业务服务器不对该订单请求进行处理。

参见上文实施例，为减小网络通信不稳定带来的影响，主控服务器和业务服务器可以分别设置限流策略。按照预置的条件，如果业务服务器判断与主控服务器的通信连接发生中断时，则执行本地的限流策略，本周期不再听从主控服务器的指令。

集群主控服务器或业务服务器对商品限流以及业务限流时采用的统计周期的设置，以及阈值的设置可参见上文的记载。

本申请实施例还提供了一种电子设备，包括存储器和处理器。

处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器上存储有可执行代码，当可执行代码被处理器处理时，可以使处理器执行上文述及的方法中的部分或全部。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关分方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

上文中已经参考附图详细描述了本申请的方案。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。本领域技术人员也应该知悉，说明书中所涉及的动作和模块并不一定是本申请所必须的。另外，可以理解，本申请实施例语调评分方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

本申请还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被计算设备(或电子设备、服务器等)的处理器执行时，使所述处理器执行根据本申请的上述语调评分方法的各个步骤的部分或全部。

本领域技术人员还将明白的是，结合这里的申请所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本申请的多个实施例的系统和语调评分方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (17)

1.一种业务限流方法，其特征在于，包括：

获得服务请求；

获得所述服务请求中携带的特定标识；

周期性的对所述服务请求进行计数，若在任一周期内获得所述特定标识的服务请求的数量达到预设阈值，则不处理所述任一周期内新接收到的携带所述特定标识的服务请求。

2.根据权利要求1所述的方法，其特征在于，若在任一周期内获得相同特定标识的服务请求数量达到预置的阈值，所述方法还包括：

向服务请求的发起端反馈拒绝处理该服务请求的通知消息。

3.根据权利要求1或2所述的方法，其特征在于：

所述特定标识包括业务类型标识；

以及，按照第一时长周期性的对所获得的服务请求进行计数，若在任一周期内获得相同业务类型标识的服务请求的数量达到第一阈值，则不处理所述任一周期内新接收到的携带所述业务类型标识的服务请求。

4.根据权利要求1或3所述的方法，其特征在于：

所述特定标识包括商品标识；

以及，按照第二时长周期性的对所获得的服务请求进行计数，若在所述任一周期内获得所述商品标识的服务请求的数量达到第二阈值；则不处理所述任一周期内新接收到的携带所述商品标识的服务请求。

5.根据权利要求4所述的方法，其特征在于：

所述第一时长与第二时长相同或者不同。

6.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

对不进行处理的服务请求进行缓存；以及，

在所述任一周期的下一个周期，所述业务服务器获得服务请求还包括获得已缓存的服务请求。

7.一种集群系统业务限流系统，其特征在于，包括：

主控服务器和多个业务服务器；

业务服务器，获得服务请求，和所述服务请求携带的特定标识；

所述主控服务器，周期性的对所述多个业务服务器所获得的服务请求进行计数，若在任一周期内获得相同所述特定标识的服务请求数量达到预置的集群阈值，则控制所述多个业务服务器不处理所述任一周期内新接收到的携带所述相同特定标识的服务请求。

8.根据权利要求7所述的系统，其特征在于，所述主控服务器控制所述多个业务服务器不处理所述任一周期内新接收到的携带该特定标识的服务请求，包括：

业务服务器，获得服务请求后，向主控服务器发送上报消息，携带所述特定标识；

主控服务器，若在所述任一周期内上报的获得相同所述特定标识的服务请求数量达到预置的集群阈值，则通知该业务服务器对所述服务请求不进行处理，否则通知该业务服务器对所述服务请求进行处理。

9.根据权利要求8所述的系统，其特征在于：

业务服务器，还周期性的根据服务请求携带的特定标识对接收到的服务请求进行计数；

以及，业务服务器向主控服务器发送上报请求后，若在预置的时间内未收到主控服务器下发的对当前服务请求是否处理的通知，并且，该业务服务器在所述任一周期内接收到的与当前服务请求携带的特定标识相同的服务请求数量达到预置的单机阈值，则对所述服务请求不进行处理。

10.根据权利要求8或9所述的系统，其特征在于：

所述特定标识包括业务类型标识；

主控服务器，按照第一时长周期性的对所获得的服务请求进行计数，若在任一第一时长周期内获得相同业务类型标识的服务请求数量达到第一集群阈值，则通知该业务服务器对所述服务请求不进行处理。

11.根据权利要求8或9所述的系统，其特征在于：

所述特定标识包括商品标识；

主控服务器，按照第二时长周期性的对所获得的服务请求进行计数，若在任一第二时长周期内获得相同商品标识的服务请求数量达到第二集群阈值，则不处理所述任一第二时长周期内新接收到的携带该业务类型标识的服务请求。

12.根据权利要求11所述的系统，其特征在于：

所述第一时长与第二时长相同或者不同。

13.根据权利要求7所述的系统，其特征在于：所述主控服务器控制所述多个业务服务器不处理所述任一周期内新接收到的携带该特定标识的服务请求，包括：

业务服务器，若在所述任一周期内，未收到来自主控服务器的对所述特定标识的服务请求不进行处理的通知消息，则向主控服务器发送上报消息，携带所述特定标识，对该服务请求进行处理；否则，不对该服务请求处理；

主控服务器，若在所述任一周期内上报的获得相同所述特定标识的服务请求数量达到预置的阈值，则通知集群的所有业务服务器，在所述任一周期内对携带该特定标识的服务请求不进行处理。

14.根据权利要求7至9其中之一所述的系统，其特征在于：

业务服务器，若对服务请求不进行处理，还进一步向所述服务请求的发起端反馈拒绝处理所述服务请求的通知消息。

15.根据权利要求14所述的系统，其特征在于：

业务服务器，还包括对所述任一周期内不进行处理的服务请求进行缓存；

以及在所述任一周期的下一个周期，所述业务服务器获得服务请求还包括获得已缓存的服务请求。

16.一种电子设备，其特征在于，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-6中任一项所述的方法。

17.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被计算设备的处理器执行时，使所述处理器执行如权利要求1-6中任一项所述的方法。

Images