分布式系统的限流方法、装置及设备与流程

本说明书涉及分布式系统技术领域，尤其涉及分布式系统的限流方法、装置及设备。

背景技术：

随着互联网技术的发展，业务系统无时无刻不面临着大流量的冲击，特别是在促销活动时，业务系统的流量更会达到前所未有的峰值。为了保证系统在面对大流量冲击的时候仍然能正常运行对外提供服务，可以将业务系统拆分成分布式系统，在一定程度上缓解这个问题。然而，但是对于一些特殊时段，流量的峰值可能会是平时流量峰值的几十倍，如何保证系统的正常运行成为亟待解决的技术问题。

技术实现要素：

为克服相关技术中存在的问题，本说明书提供了分布式系统的限流方法、装置及设备。

根据本说明书实施例的第一方面，提供一种分布式系统的限流方法，所述分布式系统中包括多个节点，所述多个节点中包括至少一个主节点和至少一个子节点，所述限流方法包括：

各个所述节点确定限流被触发后，将负载均衡器发送的待处理请求拦截至消息处理队列中；

所述主节点从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点；

所述子节点接收到所述主节点分发的待处理请求后，执行请求处理流程。

可选的，所述主节点按照设定周期从所述消息处理队列选取所述待处理请求。

可选的，所述主节点由所有节点通过选举机制被选举得到。

可选的，所述确定限流被触发，包括：待处理请求的数量达到设定限流阈值，或者是接收到设定限流指令。

可选的，所述方法还包括：各个所述节点还将负载均衡器发送的待处理请求备份于数据库中。

可选的，所述方法还包括：针对处理完成的待处理请求，在数据库中更新该请求的处理状态。

可选的，所述方法还包括：若所述消息处理队列运行异常，所述主节点从所述数据库中选取待处理请求。

可选的，所述主节点是按照优先级从所述消息处理队列选取设定数量的待处理请求。

根据本说明书实施例的第二方面，提供一种分布式系统的限流方法，所述方法应用于分布式系统中任一节点，所述方法包括：

确定限流被触发后，将负载均衡器分发的待处理请求拦截至消息处理队列中；

确定自身是主节点或者是子节点；

若是主节点，从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点；

若是子节点，则接收到主节点分发的请求后，执行请求处理流程。

可选的，所述主节点按照设定周期从所述消息处理队列选取所述待处理请求。

可选的，所述主节点由所有节点通过选举机制被选举得到。

可选的，所述确定限流被触发，包括：待处理请求的数量达到设定限流阈值，或者是接收到设定限流指令。

可选的，所述方法还包括：将负载均衡器发送的待处理请求备份于数据库中。

可选的，所述方法还包括：针对处理完成的待处理请求，在数据库中更新该请求的处理状态。

可选的，所述方法还包括：若所述消息处理队列运行异常，所述主节点从所述数据库中选取待处理请求。

可选的，所述主节点是按照优先级从所述消息处理队列选取设定数量的待处理请求。

根据本说明书实施例的第三方面，提供一种分布式系统的限流装置，所述装置应用于分布式系统中任一节点，所述装置包括：

拦截模块，用于：确定限流被触发后，将负载均衡器分发的待处理请求拦截至消息处理队列中；

确定模块，用于：确定自身是主节点或者是子节点；

分发模块，用于：若是主节点，从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点；

处理模块，用于：若是子节点，则接收到主节点分发的请求后，执行请求处理流程。

可选的，所述主节点按照设定周期从所述消息处理队列选取所述待处理请求。

可选的，所述主节点由所有节点通过选举机制被选举得到。

可选的，所述拦截模块，还用于：待处理请求的数量达到设定限流阈值，或者是接收到设定限流指令。

可选的，所述装置还包括备份模块，用于：将负载均衡器发送的待处理请求备份于数据库中。

可选的，所述方法还包括：针对处理完成的待处理请求，在数据库中更新该请求的处理状态。

可选的，所述分发模块还用于：若所述消息处理队列运行异常，所述主节点从所述数据库中选取待处理请求。

可选的，所述主节点是按照优先级从所述消息处理队列选取设定数量的待处理请求。

根据本说明书实施例的第四方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现前述限流方法。

本说明书的实施例提供的技术方案可以包括以下有益效果：

本说明书实施例中，分布式系统的限流方案可以在需要限流时，各个节点拦截负载均衡器分发的待处理请求至消息处理队列中，由主节点从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点进行处理。本实施例可以从全局流量的角度来控制整个系统的流量，在节省系统资源的情况下，可以保护系统在大流量冲击的情况下仍然能正常对外提供服务，从而达到保护系统的目的。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书根据一示例性实施例示出的一种业务场景示意图。

图2A是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图。

图2B是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图。

图2C是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图。

图2D是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图。

图3是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图。

图4是本说明书根据一示例性实施例示出的分布式系统的限流装置所在计算机设备的一种硬件结构图。

图5是本说明书根据一示例性实施例示出的一种分布式系统的限流装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

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

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着互联网的快速发展，互联网应用在访问量快速增长的同时，业务系统无时无刻不面临着大流量的冲击，如果不能在大流量冲击下仍然能正常对外提供服务，那么整个系统很可能会在大流量冲击下瘫痪，虽然业务系统可以通过分布式拆分扩容，但是有时候业务系统的流量并不是一直都会面临很大的流量，大流量有可能只是发生在促销活动期间，如果专门为了应对短期的大流量而进行系统扩容，在之后很长一段时间内，分布式系统有很大一部分的资源其实都是处于空闲的状态，进而浪费了系统资源。

本说明书实施例针对上述分布式系统场景，提供了一种限流方案，可以从全局流量的角度来控制整个系统的流量，在节省系统资源的情况下，可以保护系统在大流量冲击的情况下仍然能正常对外提供服务，从而达到保护系统的目的。

如图1所示，是本说明书根据一示例性实施例示出的一种业务场景示意图，图1中包括有：多个请求发起方、包括多个节点的分布式系统和负载均衡器；其中，负载均衡器与分布式系统中的各个节点连接，负载均衡器可以承接各个请求发起方发起的待处理请求，将待处理请求分配给分布式系统中的节点。

当面临大流量时，负载均衡器分配给各节点的请求数量很多，有可能超出节点所能承受的范围。本实施例的方案从限制分布式系统的全局流量出发，提出了一种分布式系统限流的解决方案，如图2A所示，是本说明书根据一示例性实施例示出的一种分布式系统的限流方法流程图，其中，所述分布式系统中包括多个节点，所述多个节点中包括至少一个主节点和至少一个子节点，包括：

在步骤202中，各个所述节点确定限流被触发后，将负载均衡器发送的待处理请求拦截至消息处理队列中。

在步骤204中，所述主节点从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点。

在步骤206中，所述子节点接收到所述主节点分发的待处理请求后，执行请求处理流程。

可选的，实际应用中可以根据需要灵活配置限流的触发时机或条件，作为例子，可以是以促销活动的开始时间作为限流的触发时机，可以是人工发起限流指令，也可以是根据流量大小自动触发限流，还可以是在分布式系统出现异常等情况进行限流等。具体的，所述确定限流被触发的一种方式是待处理请求的数量达到设定限流阈值，其中，该限流阈值可以根据需要灵活设定，基于此，本实施例可以在分布式系统中监视系统当前总流量的大小，如果超过设置的限流阀值，则动态触发限流，并根据后台配置的一定时间段内流量的大小来动态限流。可选的，确定限流被触发的其他方式还可以接收到设定限流指令，动态限流的开关也可以通过后台配置由人工触发，从而达到保护分布式系统的目的。

本实施例中，分布式系统中流量的大小可以通过对待处理请求的数量的计算来实现。如图2B所示，分布式系统可以收集当前系统中的流量，例如可以通过每次请求都全局记一次数，作为例子，可用Redis的Incr)实现，其中，Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。Redis的Incr命令能将key中储存的数字值增一。具体的，系统中各个节点连接同一个Redis(独立及其或者是集群都是可以的)，节点对于每个待处理请求都记一次数(调用Redis的Incr实现)，使得Redis中记录分布式系统的整体流量。可以理解，实际应用中可根据需要灵活选择其他方式，本实施例对此不做限定。

另外，可以在分布式系统的后台配置限流阈值(可选的，可以是单位时间内的最大请求数)，当系统流量达到限流阈值，可自动开启限流开关，确定执行限流处理；在其他例子中，也可以是人工在后台触发限流开关，之后分布式系统开始进行限流处理。

本实施例中，分布式系统中的节点会接收到负载均衡器发送的待处理请求，若分布式系统的流量正常未启动限流，则分布式系统中各节点接收到负载均衡器发送的待处理请求后，会直接对待处理请求进行处理。在需要限流的情况下，本实施例中各节点对于负载均衡器发送的待处理请求不会直接进行处理，而是将待处理请求拦截至消息处理队列中(可选的，可以采用Redis的优先级队列zset实现)，由主节点从消息处理队列中捞取设定数量的请求后分配给各个节点进行处理。本实施例利用主节点限制了待处理请求的数量，可以防止大流量对各个节点的冲击。

可选的，为了防止消息处理队列异常而导致的问题，待处理请求还可以同时备份至数据库，以用作兜底数据，在消息处理队列异常情况下，还可以从数据库中获取到待处理请求。

本实施例中可以从分布式系统各个节点中确定一个主节点(Master节点)，用于后续的消息分发。可选的，确定主节点可以有多种实现方式。在一些例子中，可以由分布式系统中各个节点根据设定规则选择其中一个节点作为主节点，可选的，该设定规则可以是随机选取，可以是基于节点软硬件资源选取等；也可以由技术人员配置。本实施例中还提供了选举机制的实现方式，主节点由所有节点通过选举机制被选举得到，由各个节点选举出一个Master节点，作为例子，可以借助Zookeeper的Master选举机制实现，其中，Zookeeper是一个分布式的、开放源码的分布式应用程序协调服务。

本实施例中，将主节点之外的其他节点称为子节点，基于此，分布式系统中各个节点可以确定自身是主节点还是子节点。对于主节点，可以从消息处理队列中选取设定数量的待处理请求分发给至少一个所述节点，可选的，可以基于负载均衡对待处理请求进行分发，分发的节点不限制是否包括主节点本身，也不限制是否分发给所有子节点或者是部分子节点。可选的，该设定数量可以基于分布式系统中所能承受的流量大小而确定，本实施例对此不做限定。其中，消息处理队列中预先配置有各种待处理请求的优先级，例如可以按照一些产品的优先级进行排序、或者是业务按照需求根据其它维度进行排序等等，实际应用中可根据需要灵活配置，本实施例对此不做限定。

可选的，由于节点对所分发的待处理请求的处理需要一定时间，主节点可以按照设定周期从从所述消息处理队列选取所述待处理请求，也即是主节点每隔一定时间选取，作为例子，设定周期为10秒，则主节点每隔10秒选取一次并进行分发，该10秒时间用于给各节点进行请求的处理。其中，该设定周期可以根据需要灵活配置，例如基于节点的处理能力而确定，本实施例对此不做限定。作为一种实现方式，可以在Master节点中配置定时任务，到定时任务的触发时间点后，从消息处理队列中按照优先级选取待处理请求，具体的选取数量可以通过后台配置的限流数确定。最后，主节点将选取的待处理请求分发给分布式系统中的节点。分布式系统中各个节点接收到请求信息后，可以按照正常的流程处理请求。

可选的，由于各个所述节点还将负载均衡器发送的待处理请求备份于数据库中，若所述消息处理队列运行异常，主节点还可以从所述数据库中选出待处理请求。其中，节点在处理完成待处理请求后，可以更新数据库中该请求的处理状态，该处理状态可以是处理完成或未处理等，因此，主节点数据库中选取待处理请求时，可以根据数据库中请求的处理状态，选取待处理请求。

接下来再通过图2C进行说明，分布式系统中各个节点可以配置一个全局的拦截器，负责拦截待处理请求。利用该拦截器，首先判断限流开关是否开启，限流开关开启有多种可能情况：例如可以是系统的流量达到后台默认触发限流的阈值；还可以是人工在后台配置触发限流策略。如果没有开始则按正常的处理逻辑正常处理请求。如果发现开启了限流开关，则将待处理请求先存入数据库中，然后将请求信息写入Redis的优先级队列Zset里面，请求的优先级信息从后台配置的优先级配置中读取。可选的，还可以返回给请求发起方该待处理请求在被处理过程的相关信息。可选的，还可以针对每一条待处理请求生成全局唯一的分布式订单号供请求发起方查询处理进度，在该待处理请求被处理完成后也可以发送消息通知请求发起方该订单号的请求信息已经处理完毕。其中，针对处理完成的待处理请求，还可以在数据库中更新该请求的处理状态。

如图2D所示，分布式系统中的各个节点都配置一个一定时间段触发的定时任务(例如多少分钟/多少秒等，可按照业务需求配置)。根据该定时任务，节点可以按照设定周期判断自身是否为Master节点，如果不是Master节点则不做任何处理，如果是Master节点则从Redis的优先级队列里面取请求信息，选取的数量从后台配置的限流的数量(多少分钟/多少秒钟等限流多少请求数)，如果从Redis里面取请求信息发生异常，则从数据库里面选取待处理请求。

对于选取的多条待处理请求，可以由主节点分发给集群中的各个节点进行处理，每个节点都会配置一个请求处理流程，当节点接收到分发的待处理请求，则触发请求处理流程，开始业务逻辑处理，处理完成后可以更新这次请求信息订单号相关数据的处理状态，还可以发送消息给请求发起方该请求处理完毕。

本实施例不同于传统的单机单实例限流方案，从全新的分布式系统限流角度出发，实时地进行限流检测，既支持自动触发限流也支持人工触发限流，具体的限流数也可以通过后台进行动态配置，而且对于请求信息的持久化除了支持从优先级队列里面选取外，还有数据库的兜底数据做支撑，保障了请求数据的稳定性。

对于请求发起方而言，限流策略对请求发起方是透明无感知的，限流前后请求发起方都可以通过一次请求的订单号主动查询请求处理状态，请求处理完成后也会通知客户端请求处理情况。对于分布式系统的负载情况，Master节点是支持选举(Zookeeper的Master选举机制)的，就算Master节点挂掉，其它节点也能通过选举机制重新成为Master节点；而且任务的分发也是负载均衡的，通过负载均衡地分发给集群中的其他节点。

本实施例从全新的分布式系统限流角度出发，实时地进行限流检测，动态开启限流策略，待处理请求可以在系统中各个节点负载均衡地被消费处理。

本实施例的限流方案对于请求发起方来说完全是透明的，开启限流策略前后客户端是无感知的，对于请求发起方来说没有负担，不需要做任何额外的处理。

本实施例中，一方面系统的限流数可以通过后台系统的配置动态扩展，另一方面，系统中处理请求的节点数也可以动态增加，仅仅只需要将应用分布式扩展即可，因为一个扩展的分布式系统节点，既是Master节点的备选节点，也是子节点，可以为请求消息的处理降低处理压力，从而缓解整个分布式系统集群的压力，达到限流的保护系统的目的。

本实施例中，一方面系统中的Master节点在挂掉后，可以由剩余的节点选举得出；另一方面在一些子节点挂掉后，对整个系统的影响也不会特别大，整个系统的流量仍可以负载均衡地分发给其它子节点。

如图3所示，是本说明书根据一示例性实施例示出的另一种分布式系统的限流方法的流程图，该方法可应用于分布式系统中任一节点，所述方法包括：

在步骤302中，确定限流被触发后，将负载均衡器分发的待处理请求拦截至消息处理队列中；

在步骤304中，确定自身是主节点或者是子节点；

在步骤306中，若是主节点，从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点；

在步骤308中，若是子节点，则接收到主节点分发的请求后，执行请求处理流程。

可选的，所述主节点按照设定周期从所述消息处理队列选取所述待处理请求。

可选的，所述主节点由所有节点通过选举机制被选举得到。

可选的，所述确定限流被触发，包括：待处理请求的数量达到设定限流阈值，或者是接收到设定限流指令。

可选的，所述方法还包括：将负载均衡器发送的待处理请求备份于数据库中。

可选的，所述方法还包括：针对处理完成的待处理请求，在数据库中更新该请求的处理状态。

可选的，所述方法还包括：若所述消息处理队列运行异常，所述主节点从所述数据库中选取待处理请求。

可选的，所述主节点是按照优先级从所述消息处理队列选取设定数量的待处理请求。

本实施例的限流方案是从分布式系统中每个节点的角度来描述，具体的处理流程可参考图2A至图2D所示实施例的描述，在此不再赘述。

与前述分布式系统的限流方法的实施例相对应，本说明书还提供了分布式系统的限流装置及其所应用的终端的实施例。

本说明书分布式系统的限流装置的实施例可以应用在计算机设备上，例如服务器或终端设备。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在文件处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本说明书分布式系统的限流装置所在计算机设备的一种硬件结构图，除了图4所示的处理器410、内存430、网络接口420、以及非易失性存储器440之外，实施例中装置431所在的服务器或电子设备，通常根据该计算机设备的实际功能，还可以包括其他硬件，对此不再赘述。

如图5所示，图5是本说明书根据一示例性实施例示出的一种装置的框图，所述装置包括：

拦截模块51，用于：确定限流被触发后，将负载均衡器分发的待处理请求拦截至消息处理队列中；

确定模块52，用于：确定自身是主节点或者是子节点；

分发模块53，用于：若是主节点，从所述消息处理队列选取设定数量的待处理请求后，将选取的待处理请求分发给至少一个所述节点；

处理模块54，用于：若是子节点，则接收到主节点分发的请求后，执行请求处理流程。

可选的，所述主节点按照设定周期从所述消息处理队列选取所述待处理请求。

可选的，所述主节点由所有节点通过选举机制被选举得到。

可选的，所述拦截模块，还用于：待处理请求的数量达到设定限流阈值，或者是接收到设定限流指令。

可选的，所述装置还包括备份模块，用于：将负载均衡器发送的待处理请求备份于数据库中。

可选的，所述方法还包括：针对处理完成的待处理请求，在数据库中更新该请求的处理状态。

可选的，所述分发模块还用于：若所述消息处理队列运行异常，所述主节点从所述数据库中选取待处理请求。

可选的，所述主节点是按照优先级从所述消息处理队列选取设定数量的待处理请求。

相应的，本说明书还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现前述分布式系统的限流方法。

上述分布式系统的限流装置中各个模块的功能和作用的实现过程具体详见上述分布式系统的限流方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。