控制远程服务调用频率的方法和装置与流程

文档序号:11959975阅读:331来源:国知局
控制远程服务调用频率的方法和装置与流程

本发明属于计算机技术领域,具体地说,涉及一种控制远程服务调用频率的方法和装置。



背景技术:

在系统交互的场景中,某个下层系统由于自身的处理性能限制,会给上层系统一个每秒调用量的阈值参考max_freq,如果上层系统对下层系统服务的调用总是大于这个频率,就会造成下层系统的吞吐压力过大、响应周期变长,严重时会导致系统崩溃。因此,上层系统需要控制自己的调用频率尽量不超过这个阈值。

现有技术中主要采取两种方法:一种是采用“一刀切”式的限流设置,系统设置一个每秒限流的数量max_limit,这个值可设置为等于或者稍微大于max_freq。然后每秒对下层系统的调用量进行统计,当小于等于它时都能正常进行调用,超出它时就强制不进行调用而直接返回失败。但这种方法的缺点是容易导致对系统之间的调用量利用不均衡,任务刚启动时出现过多的调用量容易导致失败,后期调用量又变得稀疏。例如图1所示的调用量曲线,限流上限设置为100tps,深色曲线为实际的调用量曲线,浅色曲线是上层系统计划要执行的调用量曲线,可以看出刚开始时调用量会过高导致部分调用不会成功,而后期调用量过低导致对调用量的利用率过低。另一种方法是调整线程数量,通过对线程数的增加或减少来控制调用量的增大和减小。但这种方法的缺点一是不精确,调用量只可按线程的比例控制,比如从10线程减少为9线程,就会把调用量减少1/10,而无法控制到1/100甚至更细的粒度;二是改造比较复杂,多一个线程和少一个线程都会对调用策略产生很大的改造成本。总之,上述对上层 系统调用频率的控制方法过于简单粗犷,系统之间的调用量利用率也较低。



技术实现要素:

有鉴于此,本申请提供了一种控制远程服务调用频率的方法和装置,解决了上层系统不能精确的自行调整调用频率的技术问题。

为了解决上述技术问题,本申请公开了一种控制远程服务调用频率的方法,包括:确定每次发起调用的预期时长;统计每次发起调用的实际时长;判断所述实际时长是否小于所述预期时长;当所述实际时长小于所述预期时长时,进入休眠状态,所述休眠状态的持续时长在所述预期时长减去所述实际时长的差的最大偏差范围之内。

所述确定每次发起调用的预期时长,包括:根据发起调用的线程数量和被调用系统的最大调用频率,确定所述预期时长。

所述预期时长expect_time=1÷max_freq×thread_num;其中,max_freq代表所述被调用系统的最大调用频率,thread_num代表所述发起调用的线程数量。

所述统计每次发起调用的实际时长,包括:记录开始处理每个事务数据时的第一时刻和每次完成调用时的第二时刻;将所述第二时刻减去所述第一时刻的差作为所述实际时长。

所述方法还包括:当所述休眠状态结束时,统计下一次发起调用的实际时长。

所述方法还包括:当所述实际时长大于或等于所述预期时长时,统计下一次发起调用的实际时长。

所述方法还包括:每隔预设周期从数据库中获取事务数据。

所述每隔预设周期从数据库中获取事务数据,包括:各个线程每次获取事务数据的数量data_num=max_freq×interval÷thread_num;其中,max_freq代表被调用系统的最大调用频率,thread_num代表发起调用的线程数量,interval代表所述预设周期。

当所述休眠状态结束时,或者当所述实际时长大于或等于所述预期时长 时,所述方法还包括:判断获取的事务数据是否全部处理完毕;当所述获取的事务数据未全部处理完毕时,统计下一次发起调用的实际时长。

为了解决上述技术问题,本申请还公开了一种控制远程服务调用频率的装置,包括:确定模块,用于确定每次发起调用的预期时长;统计模块,用于统计每次发起调用的实际时长;第一判断模块,用于判断所述实际时长是否小于所述预期时长;休眠模块,用于当所述实际时长小于所述预期时长时,进入休眠状态,所述休眠状态的持续时长在所述预期时长减去所述实际时长的差的最大偏差范围之内。

所述确定模块包括:确定子模块,用于根据发起调用的线程数量和被调用系统的最大调用频率,确定所述预期时长。

所述预期时长expect_time=1÷max_freq×thread_num;其中,max_freq代表被调用系统的最大调用频率,thread_num代表发起调用的线程数量。

所述统计模块包括:记录子模块,用于记录开始处理每个事务数据时的第一时刻和每次完成调用时的第二时刻;处理子模块,用于将所述第二时刻减去所述第一时刻的差作为所述实际时长。

所述统计模块,进一步用于当所述休眠状态结束时,统计下一次发起调用的实际时长。

所述统计模块,进一步用于当所述实际时长大于或等于所述预期时长时,统计下一次发起调用的实际时长。

所述装置还包括:获取模块,用于每隔预设周期从数据库中获取事务数据。

所述获取模块各个线程每次获取事务数据的数量data_num=max_freq×interval÷thread_num;其中,其中,max_freq代表被调用系统的最大调用频率,thread_num代表发起调用的线程数量,interval代表所述预设周期。

所述装置还包括:第二判断模块,用于当所述休眠状态结束时,或者当所述实际时长大于或等于所述预期时长时,判断获取的事务数据是否全部处理完毕;所述统计模块,进一步用于当所述获取的事务数据未全部处理完毕 时,统计下一次发起调用的实际时长。

与现有技术相比,本申请可以获得包括以下技术效果:发起调用的实际时长小于预期时长时,通过休眠来弥补实际时长与预期时长的时间差,暂缓继续发起下一次调用,从而达到精确控制调用频率的效果。

当然,实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。

附图说明

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

图1是现有技术中采用限流模式进行控制时的调用量曲线示意图;

图2是本申请实施例提供的一种控制远程服务调用频率的方法的流程示意图。

图3是采用本申请实施例提供的控制远程服务调用频率的方法时的调用量曲线示意图;

图4是本申请实施例的应用场景示意图;

图5是本申请实施例提供的一种控制远程服务调用频率的方法的流程示意图。

图6是本申请实施例提供的一种控制远程服务调用频率的方法的流程示意图。

图7是本申请实施例提供的一种控制远程服务调用频率的装置的结构示意图。

具体实施方式

以下将配合附图及实施例来详细说明本发明的实施方式,藉此对本发明如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解 并据以实施。

图2是本申请实施例提供的一种控制远程服务调用频率的方法,适用于服务器系统,该方法包括以下步骤。

在步骤S10中,确定每次发起调用的预期时长。

服务器系统根据被调用系统的最大调用频率max_freq,确定每次发起调用的预期时长。该预期时长为一个固定值,代表向该被调用系统发起的两次调用之间的时间间隔。

在步骤S11中,统计每次发起调用的实际时长。

该实际时长为每次发起调用的过程所实际耗费的时长。

在步骤S12中,判断实际时长是否小于预期时长;

由于该预期时长是根据被调用系统的最大调用频率确定的,因此如果每次调用的实际时长都小于该预期时长,则实际的调用频率会高于被调用系统的最大调用频率,会导致被调用系统的吞吐压力过大。

在步骤S13中,当实际时长小于预期时长时,进入休眠状态,休眠状态的持续时长在预期时长减去实际时长的差的最大偏差范围之内。

为了防止实际调用频率高于被调用系统的最大调用频率的情况出现,当每次调用的实际时长小于预期时长时,强制本地系统进入休眠状态。该休眠状态的持续时长在预期时长减去实际时长的差的最大偏差范围之内。即该休眠状态的持续时长可以是预期时长减去实际时长的差,或者略大或略小于该预期时长减去实际时长的差。当休眠状态的持续时长略小于预期时长减去实际时长的差时,有可能会出现实际调用频率略大于被调用系统的最大调用频率的情形,从而导致系统触发限流策略。因此,优选的休眠状态的持续时长应等于或略大于预期时长减去实际时长的差,并且该最大偏差范围不宜过大,如果该最大偏差范围过大会降低系统流量的利用率,该最大偏差范围优选在该预期时长减去实际时长的差的±2%以内。例如,每次调用的预期时长为100ms,即两次调用之间预期的时间间隔为100ms,当前完成一次调用的实际时长为80ms,则预期时长减去实际时长的差为20ms,预期时长减去实际时长的差的最大偏差范围是19.96ms-20.04ms,为了避免触发系统的限 流策略,休眠状态的持续时长优选在20ms-20.04ms。

当每次调用的实际时长小于预期时长时,通过休眠来弥补与预期时长之间的时间差,从而精确控制本地的调用频率,防止实际调用频率高于被调用系统的最大调用频率的情况出现。

当实际时长大于或等于预期时长时,则返回步骤S11,继续统计下一次发起调用的实际时长;当步骤S13中的休眠状态结束后,返回步骤S11,继续统计下一次发起调用的实际时长。

采用上述控制远程服务调用频率的方法,向被调用系统发起调用时的调用量曲线示意图如图3所示,与图1所示的现有技术中采用限流模式下的调用量曲线相比,本申请实施例提供的控制远程服务调用频率的方法会产生更合理的调用量利用效果,只会存在定时任务切换之间为了全局数据容量保护而做出调整时所带来的轻微调用量损失,如果定时任务周期越长,调整的次数就越少,这种调用量的损失也会越少。调用量在由被调用系统的最大调用频率所限制的数值以下持续动态调整,不会触发限流模式生效,实现了对调用量的平滑处理,更充分的利用本系统与被调用系统之间的调用量。

图4是本申请实施例提供的控制远程服务调用频率的方法的应用场景示意图,包括数据库和系统A和系统B。系统A根据预设周期从数据库中获取事务数据,经过本地的数据处理后,再远程调用系统B的远程服务函数完成后续的数据处理。其中,系统B作为系统A的下层系统,向系统A提供远程服务函数,根据该远程服务函数的性能向系统A提供最大调用频率max_freq;系统A采用多线程并行处理的方式,每隔预设周期interval从数据库中获取一批事务数据,以及向系统B提供的远程服务函数发起调用。系统A向系统B发起调用的线程数量为thread_num,则每个线程一次获取事务数据的数量data_num=max_freq×interval÷thread_num。由于受系统B的最大调用频率max_freq所限,系统A每隔预设周期interval从数据库获取的事务数据量应小于或等于max_freq×interval,即以该最大调用频率max_freq为基准,获取在预设周期interval这一时长内B系统所能够承受的最大事务数据量。系统A若采用多线程并行处理的方式,则每个线程一次获取事务数据的数量data_num=max_freq×interval÷thread_num,使系统A 每隔预设周期获取的事务数据量都在系统B的承受能力之内。例如,系统B提供的最大频率max_freq=100tps(Transactions Per Second,事务数每秒),系统A从数据库获取数据的预设周期interval=1s,并且通过10个线程并行从数据库获取事务数据,则每个线程一次获取事务数据的数量data_num=100t/s×1s÷10=10t(Transactions,事务数)。实现了根据被调用系统提供的最大调用频率控制每次从数据库获取到的事务数据量,确保不超过下层系统的承受能力。那么系统A在保证了获取的事务数据量不超过系统B的承受能力后,就要进一步去控制向系统B发起调用的频率,使调用量平稳可控,既充分利用系统A与系统B之间的调用量,同时要防止出现向系统B瞬时发起的调用量过高的现象出现。

系统A需要确定每次发起调用的预期时长,该预期时长代表系统A向系统B发起的两次调用之间的时间间隔。因此,系统A根据发起调用的线程数量thread_num和被调用系统的最大调用频率max_freq,确定各个线程每次发起调用的预期时长(两次调用之间的时间间隔)expect_time=1÷max_freq×thread_num。由于系统B提供的最大调用频率为max_freq,则系统A向系统B发起调用的时间间隔应大于或等于1÷max_freq,如果系统A采用多线程并行向系统B发起调用,则每个线程发起调用的预期时长应大于或等于1÷max_freq×thread_num。例如,系统B提供的最大频率max_freq=100tps,系统A通过10个线程并行向系统B发起调用,则每个线程发起调用的预期时长expect_time=1÷100tps×10=100ms/t,即系统A每个线程向系统B发起调用的预期时长(发起两次调用之间的时间间隔)的最小值应为100ms。如果实际时长小于该预期时长,则说明系统A向系统B发起调用的频率超出了系统B的承受力,因此系统A接下来要统计每次向系统B发起调用的实际时长,来判断是否超过了系统B提供的最大调用频率。

系统A统计每次发起调用的实际时长的方法如图5所示,包括以下步骤。

在步骤S20中,记录开始处理每个事务数据时的第一时刻。

由于每次发起调用的预期时长是指两次调用的之间的时间间隔,因此统 计每次发起调用的实际时长时要把系统A处理事务数据的所消耗的时长计算在内,要在系统A开始处理每个事务数据时记录该第一时刻,做为计算实际时长的初始时刻。当系统A采用多线程并行的方式向系统B发起调用时,则记录各个线程开始处理每个事务数据时的第一时刻。

在步骤S21中,系统A处理事务数据。

在步骤S22中,系统A对系统B发起远程调用。

在步骤S23中,记录当系统A完成对系统B的远程调用时的第二时刻。

该第二时刻做为计算实际时长的结束时刻。

在步骤S24中,将第二时刻减去第一时刻的差作为实际时长。

在步骤S25中,判断实际时长是否小于预期时长。当实际时长小于预期时长时,执行步骤S26;当实际时长大于或等于预期时长时,返回步骤S20。

在步骤S26中,系统A进入休眠状态,该休眠状态的持续时长在预期时长减去实际时长的差的最大偏差范围之内。

实际时长小于预期时长时,代表当前的调用频率高于系统B的最大调用频率,系统B的吞吐压力会过大。为了延缓系统A发起下一次调用,强制系统A进入休眠状态,以弥补实际时长与预期时长之间的时间差。当休眠状态的持续时长达到预期时长减去实际时长的差时,结束该休眠状态,开始统计下一次发起调用的实际时长,即返回步骤S20,记录下一次开始处理事务数据时的第一时刻。实际时长大于或等于预期时长时,代表当前的调用频率小于或等于系统B的最大调用频率,处于系统B的承受能力之内,能够立即发起下一次调用,此时开始统计下一次发起调用的实际时长,即返回步骤S20,记录下一次开始处理事务数据时的第一时刻。

在一个实施例中,当步骤S26中的休眠状态结束之后,或者在步骤S25中判断出实际时长大于或等于预期时长而需要返回步骤S20之前,如图6所示,还包括以下步骤。

在步骤S27中,系统A判断获取的事务数据是否全部处理完毕。当获取的事务数据已全部处理完毕时,则结束本流程;当获取的事务数据未全部处理完毕时,返回步骤S20。通过该步骤S27的辅助,系统A能够更准确的 控制对获取的事务数据的处理过程,确保获取的事务数据能够及时处理,在保持平稳的调用量的同时也保证事务数据的处理效率。

利用上述处理流程能够防止因网络传输状态或者自身的数据处理性能发生抖动而出现瞬时调用量过高的情况。例如,在没有采用上述处理流程的情况下,系统A与系统B之间的网络传输性能突然下降,会使系统A对系统B发起远程调用所耗费的时间增多,而当系统A与系统B之间的网络传输性能又突然恢复时,会出现系统A在瞬时向系统B发起多次调用的情况,调用频率在瞬时会高于系统B提供的最大调用频率,而采用了上述处理流程,就能在出现上述情况时,把系统A对系统B的调用频率控制在系统B的承受能力之内。同理,当系统A自身的数据处理性能出现抖动时,通过上述处理流程也能够避免出现系统A对系统B的调用频率在瞬时过高的情况。

图7是本发明实施例提供的控制远程服务调用频率的装置,包括:

确定模块30,用于确定每次发起调用的预期时长;

统计模块31,用于统计每次发起调用的实际时长;

第一判断模块32,用于判断实际时长是否小于预期时长;

休眠模块33,用于当实际时长小于预期时长时,进入休眠状态,休眠状态的持续时长在预期时长减去实际时长的差的最大偏差范围之内。

该确定模块包30包括:确定子模块,用于根据发起调用的线程数量和被调用系统的最大调用频率,确定预期时长。

该预期时长expect_time=1÷max_freq×thread_num;其中,max_freq代表被调用系统的最大调用频率,thread_num代表发起调用的线程数量。

该统计模块31包括:记录子模块,用于记录每次发起调用时的第一时刻和每次完成调用时的第二时刻;处理子模块,用于将第二时刻减去第一时刻的差作为实际时长。

在一个实施例中,该统计模块31,进一步用于当所述休眠状态结束时,统计下一次发起调用的实际时长;当所述实际时长大于或等于所述预期时长时,统计下一次发起调用的实际时长。

该装置还包括获取模块34,用于每隔预设周期从数据库中获取事务数据。该获取模块34每次获取事务数据的数量data_num=max_freq×interval÷thread_num;其中,max_freq代表被调用系统的最大调用频率,thread_num代表发起调用的线程数量,interval代表所述预设周期。

在一个实施例中,该装置还包括:第二判断模块35,用于当休眠状态结束时,或者当实际时长大于或等于预期时长时,判断获取的事务数据是否全部处理完毕;

则该统计模块31,进一步用于当获取的事务数据未全部处理完毕时,统计下一次发起调用的实际时长。

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

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

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

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解,硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式,而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语,故应解释成“包含但不限定于”。“大致”是指在可接收 的误差范围内,本领域技术人员能够在一定误差范围内解决所述技术问题,基本达到所述技术效果。此外,“耦接”一词在此包含任何直接及间接的电性耦接手段。因此,若文中描述一第一装置耦接于一第二装置,则代表所述第一装置可直接电性耦接于所述第二装置,或通过其他装置或耦接手段间接地电性耦接至所述第二装置。说明书后续描述为实施本发明的较佳实施方式,然所述描述乃以说明本发明的一般原则为目的,并非用以限定本发明的范围。本发明的保护范围当视所附权利要求所界定者为准。

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

上述说明示出并描述了本发明的若干优选实施例,但如前所述,应当理解本发明并非局限于本文所披露的形式,不应看作是对其他实施例的排除,而可用于各种其他组合、修改和环境,并能够在本文所述发明构想范围内,通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围,则都应在本发明所附权利要求的保护范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1