CN111935782B - 客户端重试机制的优化方法、存储介质 - Google Patents
客户端重试机制的优化方法、存储介质 Download PDFInfo
- Publication number
- CN111935782B CN111935782B CN202010607188.1A CN202010607188A CN111935782B CN 111935782 B CN111935782 B CN 111935782B CN 202010607188 A CN202010607188 A CN 202010607188A CN 111935782 B CN111935782 B CN 111935782B
- Authority
- CN
- China
- Prior art keywords
- request
- client
- current limiting
- interface
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供客户端重试机制的优化方法、存储介质,方法包括:服务端的一接口进入限流状态后,若接收客户端发送的对应所述一接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数;客户端依据所述异常信息,计算得到所述请求的限流等待时间;若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求。本发明能够减少客户端发起不必要的重试次数,不仅减少服务器压力,而且节省客户端和服务端的资源;进一步地,还能提高客户端重试的成功率。
Description
技术领域
本发明涉及服务端与客户端交互领域,具体涉及客户端重试机制的优化方法、存储介质。
背景技术
移动互联网蓬勃发展的今天,发展出来了各种各样的系统应用,系统之间存在各种数据交互。数据交互的方式多种多样,有通过接口进行数据访问、直接通过数据库进行交互访问、通过MQ进行消息通信等方式。通过http协议或者RPC等方式调用接口进行数据交互是现在互联网场景中最常见的方式。使用这种方式能够快速进行多系统的数据交互,提高效率。
现在的服务端处理请求任务中,为了确保服务端的稳定性与可用性,针对重要的接口都会进行限流操作。当客户端请求流量暴增时,会启动限流操作,在规定阀值之内的请求可以正常响应,超过限流阀值的请求,将会丢弃,并返回限流的异常信息。此时,客户端获取到接口返回失败的信息后,将会启动重试机制,而由于系统已经处于限流状态,客户端重试机制将会进一步扩大请求量,并且再次重试也依然有较大概率被服务端限流。
旧有客户端的失败重试机制,一般情况下使用默认重试规则,比如统一设置重试时间,达到一定时间之后进行重试,或者采用生成一个随机数时间,在该时间点进行重试。采用上述方式,服务端即使已经进入限流状态,客户端还是会源源不断地请求服务端,这样将造成请求量剧增,影响服务端的稳定性和可用性。
发明内容
本发明所要解决的技术问题是:提供客户端重试机制的优化方法、存储介质,能够减少客户端不必要的重试次数,减少服务器压力。
为了解决上述技术问题,本发明采用的技术方案为:
客户端重试机制的优化方法,包括:
服务端的一接口进入限流状态后,若接收客户端发送的对应所述一接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数;
客户端依据所述异常信息,计算得到所述请求的限流等待时间;
若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求。
本发明提供的另一个技术方案为:
一种计算机可读存储介质,其上存储有计算机程序,所述程序在被处理器执行时,能够实现如上述客户端重试机制的优化方法所包含的步骤。
本发明的有益效果在于:服务端端口进入限流状态后,便通过本地缓存对其超出限流的请求进行计数,并返回对应的限流排位和限流阈值;客户端能够依据返回数据计算得到发起重试后理想的处理该请求的等待时间,据此判断是否有必要进行重试。由此,客户端便能够依据服务端当前实际的负载情况确定重试的可行性,不仅能够减少客户端不必要的重试次数,同时减少服务器的压力;而且能够提高客户端重试的成功率。
附图说明
图1为本发明一实施例一种客户端重试机制的优化方法的流程示意图;
图2为本发明实施例一一种客户端重试机制的优化方法的流程示意图。
具体实施方式
为详细说明本发明的技术内容、所实现目的及效果,以下结合实施方式并配合附图予以说明。
本发明最关键的构思在于:服务端的接口进入限流状态后再接收到客户端请求,将返回对应的限流排位和限流阈值;客户端能够据此判断重试请求的等待时间是否超出超时时间,确定是否有必要重试。
请参照图1,本发明提供客户端重试机制的优化方法,包括:
服务端的一接口进入限流状态后,若接收客户端发送的对应所述一接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数;
客户端依据所述异常信息,计算得到所述请求的限流等待时间;
若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求。
从上述描述可知,本发明的有益效果在于:当服务端的某一接口进入到限流状态时,使用独立的本地内存数据结构对该接口超过限流阈值的请求进行统计,在每个超过限流的请求数据需要返回数据时,同时带上其限流阀值以及本次请求超过限流数量的排序位置;当客户端接收到服务端限流异常后,将依据返回数据计算得到重试请求的处理等待时间,作为判断是进行重试,还是直接返回失败状态。通过这种方式能够减少客户端发起不必要(无用)的重试请求的次数,减少服务器的压力,提高服务端器的响应效率。
进一步地,所述客户端依据所述异常信息,计算得到所述请求的限流等待时间,包括:
客户端依据异常信息中的限流阈值计算得到服务端处理每个请求的耗时;
依据所述耗时和异常信息中的所述限流计数,计算得到对应请求的限流等待时间。
由上述描述可知,客户端将粗算出服务端处理一个请求的耗时,然后依据理论上限流排位中的每个请求都将发起重试,计算得到处理到重试的该请求所需等待的时间,若该时间超出了客户端的超时时间,对于客户端而言即使返回了请求响应也没有意义,因此,通过上述计算,能准确地确定重试该请求的必要性,规避无效的重试请求,从而同时节省客户端和服务端的资源,减少服务端的压力。
进一步地,所述更新存储在本地的对应所述一接口的限流计数,包括:
更新存储在本地的对应所述一接口的缓存数据,所述缓存数据以接口标识为key,以限流计数为value。
由上述描述可知,以独立的字典形式的数据结构存储各个接口与其超出限流阈值后请求数量的关联关系,具有统计数据准确、占用内存少和易于管理等优点。
进一步地,所述客户端依据所述异常信息,计算得到所述请求的限流等待时间,之前,还包括:
客户端判断收到的异常信息是否属于服务端限流异常;
若否,则重试所述请求;
若是,则执行所述客户端依据所述异常信息,计算得到所述请求的限流等待时间步骤。
由上述描述可知,能够通过客户端对异常类型进行判断,过滤掉不属于服务端限流情况的请求重试判断,因为此种情况均有必要进行重启;因此,能够使得本发明的重试判断更具针对性。
本发明提供的另一个技术方案为:
一种计算机可读存储介质,其上存储有计算机程序,所述程序在被处理器执行时,能够实现如下述客户端重试机制的优化方法所包含的步骤:
服务端的一接口进入限流状态后,若接收客户端发送的对应所述一接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数;
客户端依据所述异常信息,计算得到所述请求的限流等待时间;
若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求。
进一步地,所述客户端依据所述异常信息,计算得到所述请求的限流等待时间,包括:
客户端依据异常信息中的限流阈值计算得到服务端处理每个请求的耗时;
依据所述耗时和异常信息中的所述限流计数,计算得到对应请求的限流等待时间。
进一步地,所述更新存储在本地的对应所述一接口的限流计数,包括:
更新存储在本地的对应所述一接口的缓存数据,所述缓存数据以接口标识为key,以限流计数为value。
进一步地,所述客户端依据所述异常信息,计算得到所述请求的限流等待时间,之前,还包括:
客户端判断收到的异常信息是否属于服务端限流异常;
若否,则重试所述请求;
若是,则执行所述客户端依据所述异常信息,计算得到所述请求的限流等待时间步骤。
从上述描述可知,对应本领域普通技术人员可以理解实现上述技术方案中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来实现的,所述的程序可存储于一计算机可读取的存储介质中,该程序在执行时,可包括如上述各方法的流程。所述程序在被处理器执行后,同样能够实现对应各方法的有益效果。
其中,所述的存储介质可以是磁盘、光碟、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。
实施例一
请参照图2,本实施例提供一种优化客户端重试机制的方法,能够针对服务端限流的情况,大大减少不必要的客户端请求重试次数,从而减少服务端的压力,提高有效请求的响应效率。
方法包括:
S1:分别配置服务端各接口的限流阈值以及客户端的超时时间。
上述各接口的限流阈值和超时时间可以直接采用默认的参数设置,也可以自行灵活配置。其中,针对服务端各接口的限流阈值,可以配置为统一数值,也可以针对接口类型或重要程度等独立配置不同的数值。例如,配置服务端重要A接口的限流阈值为100,则对应该接口的请求量超过100后,服务端将返回异常信息。
S2:当服务端的一接口的请求量达到其限流阈值而进入限流状态后,若接收到客户端发送的对应该接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数。
具体而言,本地中存储的是该接口对应的限流计数。所述限流计数对应某一接口在限流阈值之后接收到请求的数量。例如,进入限流状态后到达第一个请求,则对应的限流计数为1;第50个则对应的限流计数为50,以此类推。
优选地,所述记录采用key,value的形式保存在本地缓存中,其中,接口标识为key,对应的限流计数为value;另外,还可以配置对应的过期时间,如1s。
在一具体实例中,服务端的上述接口进入限流状态后,当对应该接口的请求到达,服务端将先依据接口标识获取本地缓存中对应的记录,然后将其对应的value值计数+1,以此类推。更新本地存储后,服务端将返回对应当前请求的异常信息,所述异常信息中至少包含两个信息:对应接口的限流阈值以及更新后的限流计数,即该请求对应的限流计数。例如,该请求是进入限流状态后接收到的第20个请求,该请求对应的接口的限流阈值为100;则对应该请求返回给客户端的异常信息中包含了限流阈值100和限流计数20两个信息。
S3:客户端接收到异常信息后,首先判断收到的异常信息是否属于服务端限流异常;
一般而言,服务端返回的异常信息基本上可以分为两类,一种是非服务端限流异常,包括了正常业务错误信息,以及请求失败,超时这类异常错误;另一种是服务端限流异常,通常会设置一个专门的异常码来表示该种异常,因此,可以通过是否存在异常码来判断是否为服务端限流异常的信息。
若不属于服务端限流异常,则按照旧有逻辑,进行重试处理;
若属于服务端限流异常,则执行S4,进入是否重试的判断过程。
S4:依据所述异常信息,计算得到所述请求的限流等待时间。
具体而言,客户端将依据异常信息中的限流阈值大概计算出服务端处理每个请求的耗时。假设限流阈值为100,则计算过程为1秒/100=0.01秒(即10毫秒处理第一个请求),其中的“1秒”是因为服务端的TPS、限流阀值等数值都是以1秒为单位进行统计的。然后,可以依据本次请求的限流计数,计算出若再次发起重试,理想地所需等待的时间。假设该请求的限流计数为300,即排在限流阈值100之后的第300个请求,则300*0.01=3秒,所述3秒为该请求的限流等待时间,也就是说,若该请求立即重试,也需要等待超过3秒的时间。因为它之前的299个请求个请求将会再次重试,其消耗的总时间为299*0.01=2.99秒。
S5:若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求。
由于限流等待时间对应的是发起重试该请求后服务端理想的处理耗时,若该时长已经超出了客户端的超时时间,因此即使得到响应,对客户端而言也已经超时无效了。因此,对此类没必要的请求重试便可过滤掉,以此节省客户端和服务端的资源,也减轻服务端的压力。
对应上一步骤的假设,若客户端的超时时间为100毫秒,即0.1秒,则由于计算得到的限流等待时间3秒已经超出了客户端超时时间,则本次请求再次重试也没有意义,选择不发起重试。再假设该请求的限流计数为5,则计算得到对应的限流等待时间为5*0.01=0.05秒,由于限流等待时间低于客户端的超时时间0.1秒,则标识该请求重试后得到响应的时间并未超出客户端超时时间,有必要发起重试。
本实施例通过对限流后接收到的请求进行计数,使得客户端能够依据请求对应的计数和接口的限流阈值计算出重试请求的限流等待时间,进而判断是否有必要进行重试。因此,本实施例能够减少客户端重试的次数,过滤没必要的重试,同时节省客户端和服务端的资源,大大减少服务端的压力。
实施例二
本实施例对应实施例一,提供一具体运用场景:
1、假设存在一个APP应用,其会调用服务端的一个获取用户信息接口(简称A接口)。该接口在服务端存在限流功能,当TPS(每秒可处理请求数)请求量超过100后,将会进入限流状态。当服务端处于限流状态后,在现有技术中,后续的请求将会被拒绝,将返回服务端限流的异常码信息。异常码信息为:UC/RATE_LIMIT。
2、假设某一秒之内,已经有100个请求来获取用户信息,这一秒中的第101个请求达到服务端时,将触发服务端限流,此时,会预先把这第101个请求在本地缓存中进行记录。具体采用key,value的形式保存在本地缓存中,其中key为A接口的标识符,value为限流的数量(即超过限流阀值的数量),过期时间为1秒。所以服务端限流后,第101个请求到达后,本地缓存的记录为:rate_limit_A接口:1;当后续第102、103个请求进来,将依次更新缓存记录数据为rate_limit_A接口:2和rate_limit_A接口:3。
3、当步骤2中记录本地缓存后,因为服务端限流,将会返回UC/RATE_LIMIT异常码信息,同时,还将返回该请求对应的A接口的限流阈值,假设为100,以及本次请求超过限流的排序位置,即当时更新的缓存记录中的限流数量,假设为第400个请求,则这边的排序位置为300。
4、此时客户端获取到步骤3中的异常信息。当异常信息为非UC/RATE_LIMIT异常码时,即非服务端限流信息时,将直接按照旧有逻辑进行判断处理并重试。
5、当异常信息为UC/RATE_LIMIT异常码时,需要在客户端进行计算,并判断是否需要重试。根据服务端返回信息中的数据可进行计算。已知晓服务端限流阀值,则每个请求具体耗时为:1秒/100=0.01秒(即10毫秒);知晓本次请求在服务端的超过限流排序为300,则可以知道300*0.01=3秒为限流数量的等待时间。此时,需要进行判断,假设A接口在客户端的超时时间为100毫秒,则本次请求可以无需再次重试,因为仍然存在299个的请求将会再次重试,其耗费的总时间将为299*0.01=2.99秒,已经超过了客户端的超时时间,再次重试请求也仍然处于被限流状态,需要等待至少3秒,及时客户端接收到响应也已经超时无效了,所以无需再次重试请求。
6、假设步骤/5中超过限流排序为5,则限流数量的等待时间为:5*0.01=0.05秒(50毫秒),则未超过客户端的超时时间,可以进行重试处理。
通过如上的客户端判断方式,可以减少客户端无意义重试的次数,并减少服务器压力。
实施例三
本实施例对应实施例一和实施例二,提供一种计算机可读存储介质,其上存储有计算机程序,所述程序在被处理器执行时,能够实现如上述实施例一或实施例二所述的客户端重试机制的优化方法所包含的步骤,具体的步骤内容在此不进行复述,详情请参阅实施例一和实施例二的记载。
综上所述,本发明提供的客户端重试机制的优化方法、存储介质,能够减少客户端发起不必要的重试次数,不仅减少服务器压力,而且节省客户端和服务端的资源;进一步地,还能提高客户端重试的成功率;本发明具有易于实施、成本低、易于管理、效果明显等特点。
以上所述仅为本发明的实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等同变换,或直接或间接运用在相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (3)
1.客户端重试机制的优化方法,其特征在于,包括:
服务端的一接口进入限流状态后,若接收客户端发送的对应所述一接口的请求,则更新存储在本地的对应所述一接口的限流计数,并返回对应所述请求的异常信息,所述异常信息包括所述一接口的限流阈值和所述限流计数,所述限流计数为所述一接口在所述限流阈值之后接收到所述请求的数量;
客户端依据所述异常信息,计算得到所述请求的限流等待时间,包括:
客户端依据异常信息中的限流阈值计算得到服务端处理每个请求的耗时;
依据所述耗时和异常信息中的所述限流计数,计算得到对应请求的限流等待时间;
所述请求的所述限流计数表示为所述请求在所述一接口在所述限流阈值之后收到所有请求中的排序数,所述请求对应的所述限流等待时间等于所述请求对应的所述限流计数与所述服务端处理每个请求的耗时的乘积;
若所述限流等待时间超出客户端的超时时间,则放弃重试所述请求,若所述限流等待时间未超出客户端的超时时间,则客户端重新发起对所述一接口的请求;
所述更新存储在本地的对应所述一接口的限流计数,包括:
更新存储在本地的对应所述一接口的缓存数据,所述缓存数据以接口标识为key,以限流计数为value,服务端先依据接口标识获取本地缓存中对应的记录,然后将其对应的value值计数+1。
2.如权利要求1所述的客户端重试机制的优化方法,其特征在于,所述客户端依据所述异常信息,计算得到所述请求的限流等待时间,之前,还包括:
客户端判断收到的异常信息是否属于服务端限流异常;
若否,则重试所述请求;
若是,则执行所述客户端依据所述异常信息,计算得到所述请求的限流等待时间步骤。
3.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述程序在被处理器执行时,能够实现如上述权利要求1和2任一所述的客户端重试机制的优化方法所包含的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010607188.1A CN111935782B (zh) | 2020-06-29 | 2020-06-29 | 客户端重试机制的优化方法、存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010607188.1A CN111935782B (zh) | 2020-06-29 | 2020-06-29 | 客户端重试机制的优化方法、存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111935782A CN111935782A (zh) | 2020-11-13 |
CN111935782B true CN111935782B (zh) | 2023-08-08 |
Family
ID=73316271
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010607188.1A Active CN111935782B (zh) | 2020-06-29 | 2020-06-29 | 客户端重试机制的优化方法、存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111935782B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113923163A (zh) * | 2021-10-20 | 2022-01-11 | 广东亿迅科技有限公司 | 一种基于长连接消息通道限流方法及系统 |
CN114449034B (zh) * | 2022-01-28 | 2024-06-25 | 湖南快乐阳光互动娱乐传媒有限公司 | 一种服务调用系统及方法 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106713171A (zh) * | 2015-07-28 | 2017-05-24 | 腾讯科技(深圳)有限公司 | 服务器、基于延时队列的限流保护系统及方法 |
CN107645456A (zh) * | 2016-07-20 | 2018-01-30 | 阿里巴巴集团控股有限公司 | 流量控制方法和流量控制系统 |
CN109743295A (zh) * | 2018-12-13 | 2019-05-10 | 平安科技(深圳)有限公司 | 访问阈值调整方法、装置、计算机设备及存储介质 |
CN109842565A (zh) * | 2018-12-15 | 2019-06-04 | 平安科技(深圳)有限公司 | 接口限流方法、装置、电子设备及存储介质 |
CN110166371A (zh) * | 2019-05-16 | 2019-08-23 | 北京达佳互联信息技术有限公司 | 流量控制方法、装置、电子设备及存储介质 |
CN110932988A (zh) * | 2019-10-31 | 2020-03-27 | 北京三快在线科技有限公司 | 流量控制方法、装置、电子设备及可读存储介质 |
CN110971561A (zh) * | 2018-09-28 | 2020-04-07 | 阿里巴巴集团控股有限公司 | 一种访问请求处理方法、装置及设备 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10212194B2 (en) * | 2014-01-20 | 2019-02-19 | Google Llc | Server controlled throttling of client to server requests |
US11153174B2 (en) * | 2018-06-15 | 2021-10-19 | Home Box Office, Inc. | Data service overload detection and mitigation |
-
2020
- 2020-06-29 CN CN202010607188.1A patent/CN111935782B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106713171A (zh) * | 2015-07-28 | 2017-05-24 | 腾讯科技(深圳)有限公司 | 服务器、基于延时队列的限流保护系统及方法 |
CN107645456A (zh) * | 2016-07-20 | 2018-01-30 | 阿里巴巴集团控股有限公司 | 流量控制方法和流量控制系统 |
CN110971561A (zh) * | 2018-09-28 | 2020-04-07 | 阿里巴巴集团控股有限公司 | 一种访问请求处理方法、装置及设备 |
CN109743295A (zh) * | 2018-12-13 | 2019-05-10 | 平安科技(深圳)有限公司 | 访问阈值调整方法、装置、计算机设备及存储介质 |
CN109842565A (zh) * | 2018-12-15 | 2019-06-04 | 平安科技(深圳)有限公司 | 接口限流方法、装置、电子设备及存储介质 |
CN110166371A (zh) * | 2019-05-16 | 2019-08-23 | 北京达佳互联信息技术有限公司 | 流量控制方法、装置、电子设备及存储介质 |
CN110932988A (zh) * | 2019-10-31 | 2020-03-27 | 北京三快在线科技有限公司 | 流量控制方法、装置、电子设备及可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111935782A (zh) | 2020-11-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110858843B (zh) | 业务请求处理方法、装置及计算机可读存储介质 | |
US7779418B2 (en) | Publisher flow control and bounded guaranteed delivery for message queues | |
CN110489447B (zh) | 数据查询方法、装置、计算机设备和存储介质 | |
US6816860B2 (en) | Database load distribution processing method and recording medium storing a database load distribution processing program | |
US8146095B2 (en) | Method, apparatus and computer program product for managing persistence in a messaging network | |
US7818386B2 (en) | Repeatable message streams for message queues in distributed systems | |
CN111935782B (zh) | 客户端重试机制的优化方法、存储介质 | |
US20070265976A1 (en) | License distribution in a packet data network | |
CN109495543B (zh) | 一种ceph集群中监视器的管理方法及装置 | |
JP2000047894A (ja) | 計算機システム | |
CN113687781A (zh) | 一种热数据的上拉方法、装置、设备及介质 | |
US8359601B2 (en) | Data processing method, cluster system, and data processing program | |
CN112114938A (zh) | 事务处理方法、装置及服务器 | |
CN113312234B (zh) | 一种健康检测的优化方法及终端 | |
CN114500416A (zh) | 用于最多一次消息投递的投递方法和投递系统 | |
CN116028142A (zh) | 聚合接口数据获取方法、装置、存储介质及计算机设备 | |
CN110865895B (zh) | 访问流量控制方法、装置、电子设备及存储介质 | |
CN110543349B (zh) | 一种应用启动加速方法、装置及计算机可读存储介质 | |
CN108718285B (zh) | 云计算集群的流量控制方法、装置及服务器 | |
CN114971163B (zh) | 重新发起业务请求的执行方法及执行装置 | |
CN111193760A (zh) | 一种信息发送方法、装置及存储介质 | |
JP4089506B2 (ja) | ファイル共有システム及びサーバー並びにプログラム | |
CN112351072B (zh) | 一种消息推送方法及终端 | |
CN116933269A (zh) | 请求转发方法及装置、存储介质、计算机设备 | |
CN118056180A (zh) | 一种数据存储装置及数据存储装置中的数据管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |