CN107196873B - 一种分布式集群的业务请求发送方法及装置 - Google Patents

Abstract

本申请公开了一种分布式集群的业务请求发送方法及装置，用以解决现有技术中对分布式集群中的各业务请求，采用的并发控制方式会降低业务的可靠性的问题。所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，所述方法包括：获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长。

Description

一种分布式集群的业务请求发送方法及装置

技术领域

本申请涉及分布式集群技术领域，尤其涉及一种分布式集群的业务请求发送方法及装置。

背景技术

在当今互联网时代的很多业务场景下，已经不是仅基于单一机构受理即可完成对所有业务请求的处理了，一般都需要多方机构互联协作才可以完成。

由于各方机构的技术能力、系统性能等方面存在差异，对于由一方发送给另一方的各业务请求，很多时候会出现发送方并发的业务请求数量过大，而接收方受理业务请求的能力较差的情况，严重的时候甚至会造成接收方系统瘫痪。在发送方为分布式集群的场景下尤其容易出现上述问题(因为分布式集群的并发能力较强)，因此，需要针对分布式集群向外部发送的业务请求进行并发控制。

在现有技术中，分布式集群内的每台机器都有一个业务请求队列用于控制业务请求发送，等待机器发送的各业务请求会进入该机器的业务请求队列排队等待发送，可以基于各机器的业务请求队列，采用外部存储计数的方式进行上述并发控制。具体地，每台机器在发送业务请求时，业务请求会从该机器的内部队列中出列，基于外部存储，可以对整个分布式集群出列的各业务请求进行计数以及发送，当计数数量到达一定数量时，暂时不允许再发送业务请求，从而可以减轻对业务请求接收方的压力。

但是，上述现有技术的方式比较滞后，在业务请求出列后才进行计数以决定是否发送该业务请求，由于分布式集群中在可能会有很多业务请求并发出列，当计数数量到达一定数量时，出列的各业务请求中可能只有一部分业务请求能够成功发送，其他业务请求则会被丢弃而无法成功发送，从而会降低业务的可靠性。

发明内容

本申请实施例提供一种分布式集群的业务请求发送方法及装置，用以解决现有技术中对分布式集群中的各业务请求，采用的并发控制方式会降低业务的可靠性的问题。

本申请实施例提供的一种分布式集群的业务请求发送方法，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，所述方法包括：

获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；

根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长。

本申请实施例提供的一种分布式集群的业务请求发送装置，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，所述装置包括：

业务请求获取模块，用于获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；

出列时间确定模块，用于根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长。

本申请实施例通过上述至少一种技术方案，可以较为平滑地对分布式集群进行并发控制，具体地，可以实现为各业务请求设置指定时长的出列时间间隔，这相当于是对各业务请求等待出列及发送的总时长进行了伸展，进而可以使得各业务请求，不会像现有技术那样从分布式集群中的各机器的业务请求队列中一涌而出，而是相对有序地、较缓地从各业务请求队列中出列以及发送，可以减轻对业务请求接收方的压力，而且也不会出现采用现有技术中的并发控制方式时，可能导致一部分业务请求被丢弃的情况发生，提高了业务的可靠性，因此，本申请的方案可以部分或全部地解决现有技术中的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的分布式集群的业务请求发送方法的过程；

图2为本申请实施例提供的，以分布式集群中的一台机器为执行主体，对图1中过程的一种实施方式的过程；

图3为本申请实施例提供的对应于图1和图2的分布式集群的业务请求发送装置结构示意图；

图4为本申请实施例提供的在实际应用中，一种用于实现图1或图2中的方法的装置；

图5为本申请实施例提供的在实际应用中，分布式集群的业务请求发送方法的一种简单过程示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的方案的思路是：对分布式集群中的各业务请求统一隐性地或显性地进行排序，按照排序顺序，以及根据各业务请求之间指定的出列时间间隔(可以对应于固定频率，也可以对应于不固定的频率)有序地、依次地对一个或多个业务请求进行出列及发送，从而可以比较平滑地处理并发，而且相比于现有技术可以提高业务的可靠性。

下面对本申请的方案进行说明。

图1为本申请实施例提供的分布式集群的业务请求发送方法的过程，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列。所述机器主要是指分布式集群中的任务机，当然，所述机器也可以是分布式集群中负责统一管理和调度各任务机的管理设备，为了便于描述，本申请主要是以所述机器是分布式集群中的任务机为例进行说明的，下面所述的“机器”主要指任务机。

图1中的方法的执行主体可以是分布式集群内的设备，也可以是分布式集群外的设备。图1中的过程主要包括以下步骤：

S101：获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求。

S102：根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长。

通过图1中的方法，可以较为平滑地对分布式集群进行并发控制，具体地，可以实现为各业务请求设置指定时长的出列时间间隔，这相当于是对各业务请求等待出列及发送的总时长进行了伸展，进而可以使得各业务请求，不会像现有技术那样从分布式集群中的各机器的业务请求队列中一涌而出，而是相对有序地、较缓地从各业务请求队列中出列以及发送，可以减轻对业务请求接收方的压力，而且也不会出现采用现有技术中的并发控制方式时，可能导致一部分业务请求被丢弃的情况发生，提高了业务的可靠性，因此，本申请的方案可以部分或全部地解决现有技术中的问题。

上面提到了图1中的方法的执行主体可以是分布式集群内的设备，具体地，执行主体可以是分布式集群中的机器(任务机)，或者，管理设备。对于这两种情况，图1的各步骤的具体实施过程可以有区别，下面主要针对前一种情况进行详细说明，之后，也会对于后一种情况进行简单说明。

在前一种情况下，图1中的过程的执行主体是分布式集群中的机器，分布式集群中的任一台机器也可以执行该方法。为了便于描述，以分布式集群中某一台机器执行该方法作为示例进行说明，在该机器执行该方法的同时，分布式集群中的其他机器也可以分别在执行该方法。

图2示出了在前一种情况下，对图1中过程的一种实施方式的过程，该过程的执行主体是分布式集群中的一台机器，该过程可以包括以下步骤：

S201：获取尚未确定业务请求队列出列时间的、等待该机器发送的各业务请求。

在本申请实施例中，分布式集群中的每台机器上可以有至少一个(一般为一个)业务请求队列，用于控制业务请求发送，该业务请求队列可以是预先就存在的，也可以是在后续实时地封装生成的。等待该机器发送的各业务请求均可以是通过该机器的业务请求队列发送的。

在现有技术中，每个业务请求的出列时间都是未预先确定的，只有在该业务请求在实际出列的时候才能够确定，可控性很差。而在本申请实施例中，则是可以根据整个分布式集群中业务请求的全局情况，分别为每个业务请求确定出一个合适的出列时间，以控制整个分布式集群单位时间内发送的业务请求数量不至于过多，可控性较强。

在本申请实施例中，对触发图2中的过程执行的因素并不做限定。该过程执行可以是基于时间因素触发的，比如，可以周期性定时地执行该过程；该过程执行也可以是基于业务请求因素触发的，当存在尚未确定出列时间的、等待该机器发送的业务请求时，可以一直持续地执行步骤S201，进一步地，可以每当获取到预定数量个(可以是一个，也可以是多个)尚未确定出列时间的、等待该机器发送的业务请求时，针对获取的这些业务请求，执行一次步骤S202和S203；等等。

在本申请实施例中，等待该机器发送的业务请求可以是由该机器自身(比如，该机器上的应用程序)生成的，也可以是由其他设备生成后传递至该机器的等。本申请对业务请求的生成相关的具体信息并不做限定，对业务请求涉及的业务的具体信息也不做限定。

进一步地，本申请实施例中的业务请求可以是等待发往分布式集群外部的，也可以是等待发往分布式集群中任意设备的。本申请实施例主要是针对前一种场景进行描述的。

S202：根据基准时间，确定所述等待该机器发送的各业务请求的出列时间，其中，所述等待该机器发送的各业务请求的出列时间间隔指定时长。

在本申请实施例中，基准时间的作用可以是：为“分布式集群中的各机器确定业务请求的出列时间”的具体实现，提供分布式集群全局的业务请求出列时间参考。

基准时间可以是存储在特定区域的，特定区域可以是分布式集群中的各机器可以访问到的存储区域，比如，指定的数据库、分布式集群的分布式缓存等。

进一步地，在每次执行步骤S202时，基准时间可以互不相同，原因是在执行图2中的过程中或过程后，一般需要由该机器或者分布式集群中的其他机器对基准时间进行更新。

在本申请实施例中，各业务请求间隔的指定时长可以是差异化的。所述指定时长设定的作用是：可以使得各业务请求每间隔一段时间出列一个或若干个，而不是在很短的时间内全部出列。通过对指定时长的合理设置，可以有效地控制出列的业务请求流量流速。

指定时长中的“指定”可以是显性地指定(比如，直接指定确定的值，作为指定时长)，也可以是隐形地指定(比如，可以通过指定某种规则，使得根据这种规则，可以确定出业务请求出列时间之间的时间间隔，作为指定时长，)，其中，出列时间相邻的两两业务请求之间间隔的指定时长可以相同，也可以不同。为了便于理解，下面举例进行说明。

例如，可以通过设置合适的指定时长，使得分布式集群中的全部业务请求以固定的或可变的频率出列及发送，每次可以出列及发送一个或多个业务请求，相邻的两次之间间隔固定的或可变的时长(在这种情况下，该时长即为：出列时间相邻的两个业务请求的出列时间之间间隔的指定时长)。这种方式相当于是对分布式集群中的全部业务请求进行了隐性的排序，以及按照该排序对各业务请求依次延迟出列。

具体地，假定当前分布式集群中共有6个业务请求，其中三个业务请求(称为a、b、c)属于分布式集群中的机器A，另外三个(称为d、e、f)属于分布式集群中的机器B。基准时间为12点(日期省略，假定本例中的日期都为同一天)，机器A根据基准时间，可以将a、b、c的出列时间分别设为12点1毫秒、12点2毫秒、12点3毫秒，然后将基准时间更新为12点3毫秒，机器B获取到的是更新后的基准时间，机器B根据基准时间，可以将d、e、f的出列时间分别设为12点4毫秒、12点5毫秒、12点6毫秒。基于上述设定，若将机器A和B视为一个整体，则从12点开始，没过1毫秒，会从该整体出列一个业务请求并发送，至少直至a、b、c、d、e、f出列发送完毕。在该例中，每次出列及发送的业务请求的数量为1个，相邻的两次之间间隔固定的时长1毫秒。

需要说明的是，上例仅是一个示例，并不构成对本申请的限定。在实际应用中，所述数量和所述时间也可以为其他值，以及还可以发生变化。

S203：根据所述等待该机器发送的各业务请求的出列时间，发送所述等待该机器发送的各业务请求。

在本申请实施例中，可以通过对出列时间和当前时间进行对比，以决定是否将该出列时间对应的业务请求出列以及发送。一般地，当前时间到达出列时间时，即可将该出列时间对应的业务请求出列以及发送。

在本申请实施例中，可以确定各业务请求的出列时间，再使各业务请求进入业务请求队列，也可以先使各业务请求进入业务请求队列，再按照队列顺序，依次为队列中的每个业务请求确定出列时间。其中，在业务请求队列中，顺序在前的业务请求的出列时间应当不晚于顺序在后的业务请求的出列时间。

通过图2中的方法，可以较为平滑地对分布式集群进行并发控制，具体地，可以实现为各业务请求设置指定时长的出列时间间隔，这相当于是对各业务请求等待出列及发送的总时长进行了伸展，进而可以使得各业务请求，不会像现有技术那样从分布式集群中的各机器的业务请求队列中一涌而出，而是相对有序地、较缓地从各业务请求队列中出列以及发送，可以减轻对业务请求接收方的压力，而且也不会出现采用现有技术中的并发控制方式时，可能导致一部分业务请求被丢弃的情况发生，提高了业务的可靠性，因此，本申请的方案可以部分或全部地解决现有技术中的问题。

基于图2中的方法，本申请实施例还提供了图2中的方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，步骤S202(或步骤S102)可以有不同的实施方式，下面对其中两种实施方式进行详细说明。

第一种方式的思路是：每确定一个业务请求，都要更新一次基准时间，其中，为了避免各机器针对基准时间的更新操作相互冲突，在同一时间可以只允许一台机器对基准时间进行更新(比如，可以基于读写锁等技术实现)。

采用第一种方式时，具体地，对于步骤S102或S202，根据基准时间，确定所述各业务请求的业务请求队列出列时间，可以包括：分别针对所述等待该机器发送的各业务请求中的每个业务请求，执行以下步骤：获取特定区域中存储的基准时间；根据获取的基准时间，确定该业务请求的业务请求队列出列时间，使该业务请求的出列时间不早于所述获取的基准时间，且与所述各业务请求中其他业务请求的出列时间间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于该业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。在针对每个业务请求，执行上述步骤的过程中，该机器可以暂时独占对基准时间的读写权限。

第二种方式的思路是：每次确定一批业务请求的出列时间，再更新一次基准时间。

采用第二种方式时，具体地，对于步骤S102或S202，根据基准时间，确定所述各业务请求的业务请求队列出列时间，可以包括：获取特定区域中存储的基准时间；根据获取的基准时间，分别确定所述等待该机器发送的各业务请求在尚未确定出列时间的、所述分布式集群中等待发送的各业务请求中的顺序；根据确定的顺序，分别确定所述等待该机器发送的各业务请求的出列时间，使所述等待该机器发送的各业务请求的出列时间不早于所述获取的基准时间，且符合所述顺序，且间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于所述等待该机器发送的各业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。

通过上述两种方式的任一种方式，相当于对整个分布式集群中全部的业务请求都进行了隐性的或显性的排序，从分布式集群这个整体的角度出发，控制分布式集群发送业务请求的速率，直观性较强，便于管控，可以提高业务的可靠性。

在本申请实施例中，所述特定区域可以是分布式集群中的各机器可以访问的存储区域。比如，特定区域可以为指定的数据库，或者，分布式集群的分布式缓存等。所述特定区域也可以是背景技术中提到的外部存储。

在本申请实施例中，前面已经提到，可以在确定各业务请求的出列时间，再使各业务请求进入业务请求队列中等待出列及发送。在这种情况下，对于步骤S103或S203，根据所述各业务请求的出列时间，发送所述各业务请求，具体可以包括：根据所述等待该机器发送的各业务请求的出列时间，按照出列时间从早至晚的顺序，对所述各等待该机器发送的各业务请求排序后封装在所述该机器的业务请求队列中；针对所述业务请求队列中的所述等待该机器发送的各业务请求，按照所述队列顺序，执行：当确定到达所述业务请求的出列时间时，将所述业务请求从所述业务请求队列中出列并发送。

一般地，业务请求队列本身可以集成有如下功能：在特定时间(比如出列时间)将业务请求队列中位于顺序最前的业务请求出列及发送。可以基于这样的功能，通过业务请求队列在出列时间，将对应的业务请求出列及发送，如此可以降低本申请的方案的实施成本。

上面以分布式集群中的机器作为执行主体，对本申请的提供的业务请求发送方法进行了详细说明。基于同样的思路，本申请实施例还提供了另一种业务请求发送方法，这种业务请求发送方法的执行主体可以是：分布式集群中的管理设备。这种业务请求发送方法的优点是：对分布式集群中的各机器影响较小，实施成本较小。

所述另一业务请求发送方法的过程可以包括以下步骤：

获取尚未确定业务请求队列出列时间的、分布式集群中等待发送的各业务请求；

按照预定规则，对所述各业务请求统一进行排序，并根据排序结果和基准时间，确定所述各业务请求的出列时间，以使所述各业务请求的出列时间间隔指定时长；

分别向分布式集群中的各机器发送指示，以使所述各机器根据所述各业务请求的出列时间，发送所述各业务请求。

需要说明的是，每台机器可以只负责发送等待该机器发送的业务请求。

以上为本申请实施例提供的分布式集群的业务请求发送方法，基于同样的思路，本申请实施例还提供对应于图1和图2的分布式集群的业务请求发送装置，如图3所示。

图3为本申请实施例提供的分布式集群的业务请求发送装置结构示意图，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，所述装置包括：

业务请求获取模块301，用于获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；

出列时间确定模块302，用于根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长。

分布式集群中的每台机器上都可以有图3中的装置，通过这些装置，可以较为平滑地对分布式集群进行并发控制，具体地，可以实现为各业务请求设置指定时长的出列时间间隔，这相当于是对各业务请求等待出列及发送的总时长进行了伸展，进而可以使得各业务请求，不会像现有技术那样从分布式集群中的各机器的业务请求队列中一涌而出，而是相对有序地、较缓地从各业务请求队列中出列以及发送，可以减轻对业务请求接收方的压力，而且也不会出现采用现有技术中的并发控制方式时，可能导致一部分业务请求被丢弃的情况发生，提高了业务的可靠性，因此，本申请的方案可以部分或全部地解决现有技术中的问题。

可选地，当图3中的装置位于所述分布式集群中的一台机器时，业务请求获取模块301具体用于：获取尚未确定业务请求队列出列时间的、等待该机器发送的各业务请求。

可选地，出列时间确定模块302具体用于：

分别针对所述等待该机器发送的各业务请求中的每个业务请求，执行：获取特定区域中存储的基准时间；根据获取的基准时间，确定该业务请求的业务请求队列出列时间，使该业务请求的出列时间不早于所述获取的基准时间，且与所述各业务请求中其他业务请求的出列时间间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于该业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。

可选地，出列时间确定模块302具体用于：获取特定区域中存储的基准时间；根据获取的基准时间，分别确定所述等待该机器发送的各业务请求在尚未确定出列时间的、所述分布式集群中等待发送的各业务请求中的顺序；根据确定的顺序，分别确定所述等待该机器发送的各业务请求的出列时间，使所述等待该机器发送的各业务请求的出列时间不早于所述获取的基准时间，且符合所述顺序，且间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于所述等待该机器发送的各业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。

可选地，所述特定区域为指定的数据库，或者，所述分布式集群的分布式缓存。

可选地，所述装置还可以包括：

业务请求发送模块303，用于根据所述等待该机器发送的各业务请求的出列时间，按照出列时间从早至晚的顺序，对所述各等待该机器发送的各业务请求排序后封装在所述该机器的业务请求队列中；针对所述业务请求队列中的所述等待该机器发送的各业务请求，按照所述队列顺序，执行：当确定到达所述业务请求的出列时间时，将所述业务请求从所述业务请求队列中出列并发送。

需要说明的是，图3中的装置的模块划分方式和名称仅是一种示例，在实际应用中，也可以通过其他装置实现图1或图2中的方法，以及达到类似的技术效果。

例如，本申请实施例还提供了在实际应用中，一种用于实现图1或图2中的方法的装置，图4为该装置的结构示意图。

图4中的装置可以包括以下模块：

队列前置处理模块，用于通过异步线程受理外部应用实现后投递的业务请求，基于分布式集群外部存储计算业务请求的出列时间；

外部存储模块，用于封装基准时间的存储逻辑(用于存储基准时间)，同时封装存储介质；

队列仓储模块，用于在确定业务请求的出列时间后，将业务请求封装进业务请求队列；

队列后置处理模块，用于采用异步线程读取业务请求队列中的元素(即，业务请求)，并基于业务请求的出列时间，计算是否将业务请求投递(即，出列及发送)给外部应用实现的接口进行外部处理；

其中，外部存储模块可以在每个所述装置上都有，或者，也可以由各所述装置共用同一个外部存储模块，或者，外部存储模块也可以不位于所述装置上，而是位于所述装置以外的其他装置上。

进一步地，本申请实施例还提供了在实际应用中，上述的分布式集群的业务请求发送方法的一种简单过程示意图，如图5所示。

在图5中示出了某个分布式集群中的若干机器(A、B、C等)。各机器分别通过一个特定区域存储的基准时间，统一地为分布式集群中待发送的业务请求计算出列时间，其中，每个机器可以只负责计算等待自己发送的各业务请求的出列时间。

在计算出出列时间后，各机器可以分别将等待自己发送的各业务请求封装进自己的业务请求队列(若该队列已存在的话)中，或者，封装为自己的业务请求队列(若该队列尚未存在的话)。并在出列时间将对应的业务请求从业务请求队列中出列及发送。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (6)

1.一种分布式集群的业务请求发送方法，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，其特征在于，所述方法包括：

获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；

根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长；

当所述方法的执行主体是所述分布式集群中的一台机器时，获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求，具体包括：

获取尚未确定业务请求队列出列时间的、等待该机器发送的各业务请求；

其中，根据基准时间，确定所述各业务请求的业务请求队列出列时间，具体包括：

分别针对所述等待该机器发送的各业务请求中的每个业务请求，执行：

获取特定区域中存储的基准时间；

根据获取的基准时间，确定该业务请求的业务请求队列出列时间，使该业务请求的出列时间不早于所述获取的基准时间，且与所述各业务请求中其他业务请求的出列时间间隔指定时长；

对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于该业务请求的出列时间；

其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间；或者,

根据基准时间，确定所述各业务请求的业务请求队列出列时间，具体包括：

获取特定区域中存储的基准时间；

根据获取的基准时间，分别确定所述等待该机器发送的各业务请求在尚未确定出列时间的、所述分布式集群中等待发送的各业务请求中的顺序；

根据确定的顺序，分别确定所述等待该机器发送的各业务请求的出列时间，使所述等待该机器发送的各业务请求的出列时间不早于所述获取的基准时间，且符合所述顺序，且间隔指定时长；

对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于所述等待该机器发送的各业务请求的出列时间；

其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。

2.如权利要求1所述的方法，其特征在于，所述特定区域为指定的数据库，或者，所述分布式集群的分布式缓存。

3.如权利要求1所述的方法，其特征在于，根据所述各业务请求的出列时间，发送所述各业务请求，具体包括：

根据所述等待该机器发送的各业务请求的出列时间，按照出列时间从早至晚的顺序，对所述各等待该机器发送的各业务请求排序后封装在所述该机器的业务请求队列中；

针对所述业务请求队列中的所述等待该机器发送的各业务请求，按照所述队列顺序，执行：当确定到达所述业务请求的出列时间时，将所述业务请求从所述业务请求队列中出列并发送。

4.一种分布式集群的业务请求发送装置，所述分布式集群包含多台机器，每台机器上有至少一个业务请求队列，其特征在于，所述装置包括：

业务请求获取模块，用于获取所述分布式集群中尚未确定业务请求队列出列时间的、等待发送的各业务请求；

出列时间确定模块，用于根据基准时间，确定所述各业务请求的出列时间，以便于所述分布式集群中的机器根据所述各业务请求的出列时间，发送所述各业务请求，其中，所述各业务请求的业务请求队列出列时间间隔指定时长；

当所述装置位于所述分布式集群中的一台机器时，所述业务请求获取模块具体用于：获取尚未确定业务请求队列出列时间的、等待该机器发送的各业务请求；

其中，所述出列时间确定模块具体用于：

分别针对所述等待该机器发送的各业务请求中的每个业务请求，执行：获取特定区域中存储的基准时间；根据获取的基准时间，确定该业务请求的业务请求队列出列时间，使该业务请求的出列时间不早于所述获取的基准时间，且与所述各业务请求中其他业务请求的出列时间间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于该业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间；

或者，所述出列时间确定模块具体用于：获取特定区域中存储的基准时间；根据获取的基准时间，分别确定所述等待该机器发送的各业务请求在尚未确定出列时间的、所述分布式集群中等待发送的各业务请求中的顺序；根据确定的顺序，分别确定所述等待该机器发送的各业务请求的出列时间，使所述等待该机器发送的各业务请求的出列时间不早于所述获取的基准时间，且符合所述顺序，且间隔指定时长；对所述特定区域中存储的基准时间进行更新，使更新后的基准时间不早于所述等待该机器发送的各业务请求的出列时间；其中，所述获取的基准时间不早于已确定的、所述分布式集群中等待发送的各业务请求的出列时间。

5.如权利要求4所述的装置，其特征在于，所述特定区域为指定的数据库，或者，所述分布式集群的分布式缓存。

6.如权利要求4所述的装置，其特征在于，所述装置还包括：

业务请求发送模块，用于根据所述等待该机器发送的各业务请求的出列时间，按照出列时间从早至晚的顺序，对所述各等待该机器发送的各业务请求排序后封装在所述该机器的业务请求队列中；针对所述业务请求队列中的所述等待该机器发送的各业务请求，按照所述队列顺序，执行：当确定到达所述业务请求的出列时间时，将所述业务请求从所述业务请求队列中出列并发送。

Images