CN114827281B - 一种网络请求的发送及接收方法、系统及装置 - Google Patents

Abstract

本公开提供了一种网络请求的发送及接收方法、系统及装置，涉及计算机网络技术领域，尤其涉及计算机网络应用技术领域。具体实现方案为：客户端在获取到待发送的网络请求后，确定当前延时时长，再按照当前延时时长进行延时后，向服务端发送该网络请求。应用本公开实施例，通过对待发送网络请求按照当前延时时长进行延时后，再进行相应的接口请求，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

Description

一种网络请求的发送及接收方法、系统及装置

技术领域

本公开涉及计算机网络技术领域，尤其涉及计算机网络应用技术领域。

背景技术

在网络服务中，经常会遇到同一时刻客户端请求量过大，超过服务端最大负载的情况，这给服务端造成巨大压力，影响了服务端的正常使用。因此，需要避免这种情况的发生，保证服务端正常使用以及网络服务的正常进行。

发明内容

本公开提供了一种用于降低同一时刻客户端请求量的网络请求的发送及接收方法、系统、装置、客户端、服务端以及存储介质。

根据本公开的一方面，提供了一种网络请求的发送方法，应用于客户端，包括：

获取当前待发送的网络请求；

确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

按照所述当前延时时长进行延时后，向服务端发送所述网络请求。

根据本公开的另一方面，提供了一种网络请求的接收方法，应用于服务端，包括：

向客户端发送预设打散范围时长；

接收客户端发送的网络请求；所述网络请求是所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送的。

根据本公开的一方面，提供了一种网络请求的发送及接收系统，包括：多个客户端以及服务端；

所述客户端，用于获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送所述网络请求；

所述服务端，用于向客户端发送预设打散范围时长；接收客户端发送的网络请求。

根据本公开的一方面，提供了一种网络请求的发送装置，应用于客户端，包括：

网络请求获取模块，用于获取当前待发送的网络请求；

延时时长确定模块，用于确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

网络请求发送模块，用于按照所述当前延时时长进行延时后，向服务端发送所述网络请求。

根据本公开的一方面，提供了一种网络请求的接收装置，应用于服务端，包括：

打散范围时长发送模块，用于向客户端发送预设打散范围时长；

网络请求接收模块，用于接收客户端发送的网络请求；所述网络请求是：所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送的。

根据本公开的一方面，提供了一种客户端，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够上述任一所述的网络请求的发送方法。

根据本公开的一方面，提供了一种服务端，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够上述任一所述的网络请求的接收方法。

根据本公开的一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行上述任一所述的网络请求的发送或接收方法。

根据本公开的一方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述任一所述的网络请求的发送或接收方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开提供的网络请求的发送方法的第一实施例的示意图；

图2是根据本公开提供的网络请求的发送方法的第二实施例的示意图；

图3是根据本公开提供的网络请求的发送方法的一种具体流程示意图；

图4是根据本公开提供的网络请求的接收方法的第一实施例的示意图；

图5是根据本公开提供的网络请求的接收方法的第二实施例的示意图；

图6是根据本公开提供的网络请求的发送及接收系统的一种结构示意图；

图7是根据本公开提供的网络请求的发送及接收系统的一种交互流程示意图；

图8是根据本公开提供的网络请求的发送装置的第一实施例的示意图；

图9是根据本公开提供的网络请求的发送装置的第二实施例的示意图；

图10是根据本公开提供的网络请求的接收装置的第一实施例的示意图；

图11是用来实现本公开实施例的网络请求的发送方法的客户端的框图；

图12是用来实现本公开实施例的网络请求的接收方法的服务端的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

现有技术中，为了避免服务器压力过大，通常会采用以下方案来降低同一时刻服务器接收到的网络请求量：方案1，通过设置loading态等防止用户快速交互造成接口短时多次请求，来使得终端设备减少单位时间内的网络请求。这种方式会极大降低用户的使用体验。方案2，减少同步请求，增加异步请求。这种方式需要在网络请求的地方，提前进行数据预加载，数据处理量较大。方案3，通过新增网络服务节点，加快内容分发。这种方式极大地增加了网络服务的成本。方案4，降低客户端短时轮训服务端接口的场景，但这种方案的可行性较低。

为了解决以上问题，本公开提供了一种网络请求的发送及接收方法、系统、装置、客户端、服务端以及存储介质。下面首先对本公开提供的网络请求的发送方法进行说明。

参见图1，图1是根据本公开提供的网络请求的发送方法的第一实施例的示意图。如图1所示，该方法可以包括：

步骤S110，获取当前待发送的网络请求。

本公开实施例中，上述待发送的网络请求可以是用户通过设备中安装的APP、上述H5页面等等客户端发出的。上述网络请求可以包括直播间进入请求、小说阅读请求以及优惠券领取请求等等。

步骤S120，确定当前延时时长。

本公开实施例中，上述延时时长random可以是基于预设的打散范围时长duration随机生成的。

在本公开的一种实施例中，上述打散范围时长可以是由人工在云端，基于用户体验以及服务端数据处理能力进行预先设置，并从服务端预先下发至客户端的。

本公开实施例中，上述随机生成的延时时长的范围可以是基于上述打散范围时长确定的。由于延时时长为随机生成，因此，可以理解为其在上述范围内的每一个取值的概率趋于相等。也就是说，该打散范围时长可以表示将各客户端发送的网络请求按照时间维度平均化的时长范围。

本公开实施例中，上述打散范围时长的单位也可以由人工进行预先设置。作为本公开的一种实施例，上述打散范围时长的单位可以是秒。

本公开实施例中，上述打散范围时长duration可控；duration越小延迟越低，用户体验越好，服务端单位时间接收的请求数越高，服务端高并发保障的效果较差；duration越大延迟越高，用户体验越差，服务端单位时间接收的请求数越低，服务端高并发保障的效果越好。因此，可以由人工综合考量用户体验以及服务端高并发保障效果，来设置打散范围时长duration。进而可以平衡由于按照时间维度对网络请求平均化打散后产生的延迟问题以及服务端高并发保障的效果，保证服务端正常运行的同时，保证用户体验。

步骤S130，按照所述当前延时时长进行延时后，向服务端发送所述网络请求。

本公开实施例中，客户端在接收到上述待发送的网络请求后，可以在按照上述随机生成的当前延时时长进行延时后，再向服务端进行相应的接口请求。

可见，本公开实施例提供的网络请求的发送方法，客户端在获取到待发送的网络请求后，确定当前延时时长，再按照当前延时时长进行延时后，向服务端发送该网络请求。应用本公开实施例，通过对待发送网络请求按照当前延时时长进行延时后，再进行相应的接口请求，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内服务端接收的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

另外，本公开提供的网络请求的发送方法中，在设置上述打散范围时长时，会综合考虑用户体验以及服务端的数据处理能力，在一定程度上保证了用户体验。且本公开实施例中，无需进行数据预加载，仅需在客户端随机生成延时时长，避免在客户端处理较多数据。同时，本公开实施例中，无需增加网络服务节点，避免了新增内容分发节点或负载均衡等带来的成本问题。在实际应用中，本公开提供的网络请求的发送方法也有较好的可行性。

本公开实施例中，上述步骤可以利用客户端内置的消息延迟系统执行。作为一种具体实施方式，该消息延迟系统可以是人工预先编写的程序代码。

本公开实施例中，上述当前延时时长可以实时确定，也可以预先进行确定。

在本公开的一种实施例中，上述步骤S120，确定当前延时时长，可以包括以下步骤：

利用随机数系统，获取在预设打散范围时长内的随机数，作为当前延时时长；所述随机数以毫秒为单位。

本公开实施例中，上述延时时长的单位可以由人工预先根据实际需要进行设置。如上所述，作为一种具体实施方式，上述延时时长的单位可以是毫秒。

本公开实施例中，上述随机数系统可以是客户端内的小程序等等。而由于本公开实施例中，利用随机数系统获取的是延时时长，因此，获取的随机数的值是大于零的。也就是说，本公开实施例中，可以利用上述随机数系统获取范围在[0，打散范围时长](单位为毫秒)区间内的随机数，作为延时时长。

如上所述，在本公开的一种实施例中，上述打散范围时长duration的单位为秒，而针对延时时长预设的单位为毫秒。因此，上述延时时长的生成区间就可以是[0，duration*1000]毫秒。

例如，若本实施例中，上述打散范围时长duration为3s(秒)，那么，就可以利用随机数系统获取范围在[0，3000]毫秒区间内的随机数，作为延时时长。例如，该延时时长可以是421ms(毫秒)。

如上所述，由于随机数系统在区间[0，duration*1000]内的每一个取值的概率趋于相等，所以针对同一时刻的高并发请求数n，通过上述步骤按照时间维度平均打散进行延迟请求后，服务端同一时刻接收到的请求数会降低到n/(duration*1000)，即可以实现降低同一时刻客户端请求数的目标。

本公开实施例中，客户端在获取上述当前延时时长后，可以将该延时时长进行存储，以基于该延时时长对上述网络请求进行延迟发送，或对该当前延时时长进行调节。

如上所述，本公开实施例中，上述当前延时时长也可以预先生成。即在本公开的一种实施例中，上述步骤S120可以包括以下步骤：

步骤1，预先利用随机数系统，获取在预设打散范围时长内的多个随机数进行保存。

步骤2，在获取当前待发送的网络请求后，从保存的多个随机数中选择任意一个随机数作为当前延时时长。

基于上述打散范围时长为3s的举例，可以预先利用随机数系统生成6个在[0，3000]毫秒区间内的随机数。在获取到上述网络请求后，可以从这6个随机数中任意选取一个作为当前延时时长。

当然，本实施例中，也可以预先利用随机数系统，基于上述打散范围时长，获取一个随机数，并将该随机数作为当前延时时长。上述当前延时时长的单位可以是毫秒。

本公开实施例中，以毫秒为单位，基于预设打散范围时长，随机生成当前延时时长，在保障服务端高并发请求处理效果的同时，最大限度地保证用户体验。

应用本公开实施例，针对短时间内的单用户多次请求，也可将其按照时间维度平均打散，降低终端设备的短时资源消耗，提高设备性能。

在本公开的一种实施例中，在图1的基础上，如图2所示，上述步骤S130之前，上述方法还可以包括以下步骤：

步骤S230，接收服务端发送的当前负载参数。

本公开实施例中，所述当前负载参数可以表明所述服务端当前是否负载过重。作为本公开实施例的一种具体实施方式，上述负载参数可以是所述服务端基于第一预设时间段内客户端请求量是否超过第一预设阈值确定的。

在本公开的一种实施例中，上述第一预设时间段内的客户端请求量可以以第一预设时间段内的QPS(Queries-per-second，每秒查询率)来衡量。作为本公开实施例的一种具体实施方式，可以预先设置服务端承载量阈值(上述第一预设阈值)，该阈值可以略小于服务端最大承载量。在服务端判断上述第一预设时间段内的QPS是否大于该阈值后，就可以向客户端返回上述负载参数isOverLoad。作为一种具体实施方式，可以通过上述客户端向服务端发送请求的接口，向客户端返回上述负载参数isOverLoad。

本公开实施例中，上述第一预设时间段可以是基于所述打散范围时长确定的。在本公开的一种实施例中，上述第一预设时间段可以是[打散范围时长]，该时间段的单位可以为毫秒。例如，基于上述打散范围时长为3s的举例，上述第一时间段就可以是[0,1500](单位毫秒)。服务端可以判断接收到客户端请求后的1.5s内，QPS是否大于上述第一预设阈值，来返回上述负载参数。

在本公开的一种实施例中，上述负载参数的值可以为true或false。本公开实施例中，若服务端判断当前负载过重，那么就可以向各客户端返回值为true的负载参数isOverLoad。若服务端判断当前未出现负载过重，就可以向各客户端返回值为false的负载参数isOverLoad。

步骤S240，基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则执行步骤S250；若确定所述服务端当前未出现负载过重，则执行步骤S260。

基于步骤S230中的举例，上述步骤S240就可以包括：若所述当前负载参数的值为true，则所述服务端当前负载过重；若所述当前负载参数的值为false，则所述服务端当前未出现负载过重。这样，客户端可以较为直接便利地通过该负载参数isOverLoad，判断服务端是否出现负载过重。进而可以及时调整当前延时时长，保证服务端正常运行的同时，提高用户体验。

图2中的步骤S250，将所述当前延时时长延长，得到更新后的当前延时时长。

本公开实施例中，若服务端当前出现负载过重情况，就说明延时时长在上述第一时间段内的客户端请求依旧过多，因此，需要减少延时时长在第一时间段内的客户端请求数量。

在本公开的一种实施例中，可以通过以下方式来更新当前延时时长：

若所述当前延时时长在所述第一预设时间段内，且为偶数，则将所述当前延时时长延长所述打散范围时长，作为更新后的当前延时时长。

基于上述第一预设时间段是[打散范围时长]毫秒的举例，若当前延时时长random∈[/>打散范围时长]且random％2＝0，那么更新后的当前延时时长就可以是打散范围时长。

例如，若上述打散范围时长为3s，那么若当前延时时长random∈[0，1500]毫秒且random％2＝0，那么更新后的当前延时时长就可以是random+1500ms。即若当前延时时长为421ms，更新后的当前延时时长就可以是1921ms。

由上可见，本公开实施例中，若服务端在第一预设时间段内还是出现负载过重，就可通过对延时时长在该第一预设时间段内且延时时长为偶数的客户端的延时时长进行延长，进而减少延时时长在第一预设时间段内的客户端数量，进一步减少同一时刻高并发请求，保证服务端正常运行。同时，由于延时时长是随机生成的，即可以理解为延时时长的奇偶分布是平均的。因此，通过对延时时长在第一时间段内且为偶数的客户端进行延时时长的延长，可以较为平均的对这些客户端请求进行打散，进一步减少同一时刻高并发请求。

步骤S260，将所述当前延时时长缩短，得到更新后的当前延时时长。

本公开实施例中，若服务端在上述第一预设时间段内未出现负载过重，那么就说明可以适量增加延时时长在该第一预设时间段内的客户端请求数量。即可以对一些客户端的延时时长进行缩短，使其延时时长落在上述预设时间段内。

在本公开的一种实施例中，可以采用以下方法缩短上述客户端延时时长：

若所述当前延时时长在第二预设时间段内，且为偶数，则将所述当前延时时长缩短所述打散范围时长，作为更新后的当前延时时长；其中，所述第二预设时间段为[/>打散范围时长，打散范围时长]。

本公开实施例中，上述第二时间段的单位也可以为毫秒。

在本公开的一种实施例中，上述第二预设时间段可以是[打散范围时长，打散范围时长]，单位为毫秒。即若客户端当前延时时长random∈[/>打散范围时长，打散范围时长]，且random％2＝0，就可以将当前延时时长缩短/>打散范围时长，使其落在上述第一预设时间段内。

基于上述打散范围时长为3s的举例，若客户端当前延时时长random∈[1500,3000]毫秒，且random％2＝0，那么就可以将当前延时时长缩短1500ms。即若客户端当前延时时长为2022ms，那么更新后的当前延时时长就可以是2022-1500＝522ms，而522ms落在[0，1500]毫秒的区间内。

当然，在本公开的一种实施例中，若上述服务端未出现负载过重，也可以不对当前延时时长进行更新。

相应的，如图2所示，上述图1中的步骤S130就可以细化为：

步骤S131，按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

本公开实施例中，在获取上述更新后的当前延时时长后，可以对该更新后的当前延时时长进行存储，使其覆盖之前存储的当前延时时长。之后就可以按照该更新后的当前延时时长对待发送的网络请求进行延时后发送。

如图3所示，图3示出了本公开实施例提供的网络请求的发送方法的一种具体流程，在程序开始后，可以执行以下步骤：

步骤S301，获取待发送网络请求。

本步骤中，上述待发送网络请求可以是用户通过设备内安装的APP或H5页面等等发送至客户端的。

步骤S302，获取平均打散时长duration。

本步骤中，上述平均打散时长(即本公开中所述打散范围时长)可以是由人工预先设置，再从云端下发至客户端的。该平均打散时长的单位可以是秒。

步骤S303，获取平均打散区间[0,duration*1000]。

本步骤中，当前延时时长的预设范围可以是毫秒。而上述打散范围时长duration的单位是秒，因此，上述平均打散区间(即生成随机数的区间)就可以是[0,duration*1000]，单位为毫秒。

步骤S304，随机数发生器[0,duration*1000]。

本步骤中，可以利用随机数发生器(即本公开中所述随机数系统，可以是小程序)，在[0,duration*1000]毫秒区间内生成随机数。

步骤S305，获得随机数random∈[0,duration*1000]。

本步骤中，上述随机数random的单位可以是毫秒。

步骤S306，消息延迟系统延迟random毫秒发送网络请求。

本步骤中，该消息延迟系统可以是预先编写的程序代码。

步骤S307，获取当前负载参数。

本步骤中，上述负载参数isOverLoad可以是服务端基于[0,(duration*1000)/2](单位为毫秒)时间段内，接收到的客户端请求的数量是否超过第一预设阈值，来判断是否出现负载过重，再为负载参数进行赋值，并返回至客户端的。例如，若出现负载过重，则向负载参数isOverLoad赋值true，返回至客户端；若未出现负载过重，则向负载参数isOverLoad赋值false，返回至客户端。

步骤S308，客户端判断服务端当前是否负载过重。若是，则执行步骤S309，若否，则执行步骤S311。

本步骤中，客户端可以基于上述负载参数判断服务端在[0,(duration*1000)/2]毫秒时间段内是否出现负载过重。若出现负载过重，则可对当前延时时长在[0,(duration*1000)/2]毫秒中的客户端数量进行减少，即延长其中部分客户端的当前延时时长。若未出现负载过重，则可对当前延时时长在[0,(duration*1000)/2]毫秒中的客户端数量进行增加，即缩短部分客户端的当前延时时长，使其当前延时时长落入[0,(duration*1000)/2]内。

步骤S309，客户端判断是否Random∈[0,(duration*1000)/2]且random％2＝0。若是，则执行步骤S310；若否，则执行步骤S306。

本步骤中，上述[0,(duration*1000)/2]区间的单位可以是毫秒。

本步骤中，若当前延时时长Random不满足上述条件，那么可以不对当前延时时长进行变化，上述消息延迟系统可依旧按照当前延时时长延迟发送用户请求。

步骤S310，Random＝Random+(duration*1000)/2。

若当前延时时长Random满足上述步骤S309中的条件，就可对当前延时时长进行延长，获取更新后的当前延时时长。之后，消息延迟系统就可按照该更新后的当前延时时长对网络请求进行延迟发送(即返回步骤S306)。

步骤S311，是否Random∈[(duration*1000)/2,duration*1000]且random％2＝0。若是，则执行步骤S312；若否，则执行步骤S306。

本步骤中，上述[(duration*1000)/2,duration*1000]区间的单位可以为毫秒。

本步骤中，若当前延时时长不满足上述条件，则可不对当前延时时长进行变化。消息延迟系统可以继续按照当前延时时长对网络请求进行延时后发送。

步骤S312，Random＝Random-(duration*1000)/2。

若当前延时时长满足步骤S311中的条件，则可对当前延时时长进行缩短，得到更新后的当前延时时长，进行存储。之后，消息延迟系统就可基于该更新后的当前延时时长对网络请求进行延时后发送(即返回步骤S306)。

可见，本公开实施例中，基于随机产生的延时时长Random对网络请求进行延迟发送。由于random具有随机性，所以在规定时长duration*1000毫秒内，可以使得本应该在同一时刻高并发的请求，按照时间尺度平均打散，延迟random毫秒后请求，减少同一时刻的客户端请求数量，降低服务端压力。

根据本公开实施例，本公开还提供了一种网络请求的接收方法，应用于服务端，如图4所示，该方法可以包括：

步骤S410，向客户端发送预设打散范围时长。

步骤S420，接收客户端发送的网络请求。

本公开实施例中，所述网络请求可以是所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送的。

本公开实施例中，服务端向客户端发送预设打散范围时长，并接收客户端发送的网络请求，该网络请求是客户端按照基于打散范围时长随机生成的当前延时时长，对待发送的网络请求进行延迟后再发送的。这样，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内的服务端接收到的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

在本公开的一种实施例中，上述步骤S410可以细化为：

在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

本公开实施例中，上述第三时间段可以由人工基于实际应用情况进行预设。其可以小于上述打散范围时长，也可以大于上述打散范围时长。上述预设第三时间段可与上述第一预设时间段相同，也可与上述第一预设时间段不同。本公开中对预设第三时间段的取值不作具体限定。

本公开实施例中，上述第二阈值可以也可以由人工进行预先设置。该第二预设阈值可以与上述第一预设阈值相等，也可以与上述第一预设阈值不等，本公开中不做具体限定。

本公开实施例中，在检测到预设第三时间段内客户端请求量超过第二预设阈值后，再向所述客户端发送预设打散范围时长，可以使得客户端仅在高并发场景中对网络请求进行延时发送，保障服务端高并发请求处理效果的同时，保证用户体验。

在本公开的一种实施例中，基于图4，如图5所示，上述方法还可以包括：

步骤S530，判断第一预设时间段内客户端请求量是否超过第一预设阈值。

本公开实施例中，所述第一预设时间段可以小于预设打散范围时长。

步骤S540，基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值。

本公开实施例中，所述当前负载参数可以表明所述服务端当前是否负载过重；

步骤S550，向所述客户端返回赋值后的当前负载参数。

本公开实施例中，所述客户端可以基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

在本公开的一种实施例中，若所述客户端请求量超过所述第一预设阈值，则向所述负载参数赋值为true；若所述客户端请求量未超过所述第一预设阈值，则向所述负载参数赋值为false。

相应的，客户端就可基于接收到的负载参数值，十分便捷地判断服务端是否出现负载过重，进一步保证延时时长调节的及时性。

上述步骤已在前述网络请求的发送方法实施例部分进行详细说明，此处仅做简单的补充说明，不再赘述。

根据本公开实施例，本公开还提供了一种网络请求的发送及接收系统，如图6所示，该系统可以包括：客户端610以及服务端620。

本公开实施例中，上述客户端可以有多个。

所述客户端610，可以用于获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送所述网络请求；

所述服务端620，可以用于向客户端发送预设打散范围时长；接收客户端发送的网络请求。

本公开实施例中，客户端在获取到待发送的网络请求后，确定当前延时时长，再按照当前延时时长进行延时后，向服务端发送该网络请求。应用本公开实施例，通过对待发送网络请求按照当前延时时长进行延时后，再进行相应的接口请求，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

在本公开的一种实施例中，上述服务端620，具体可以用于在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

在本公开的一种实施例中，所述服务端620，还可以用于判断第一预设时间段内客户端请求量是否超过第一预设阈值；其中，所述第一预设时间段小于预设打散范围时长；基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值；向所述客户端返回赋值后的当前负载参数

所述客户端610，还可以用于接收服务端发送的当前负载参数；基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；

所述客户端610按照所述当前延时时长进行延时后，向服务端发送所述网络请求，可以包括：

按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

如图7所示，图7是本公开提供的网络请求的发送及接收系统的一种交互流程图，具体可以包括以下步骤：

步骤S701，服务端向客户端发送预设打散范围时长。

本实施例中，上述打散范围时长duration可以是由人工预设并从云端下发至客户端的。其单位可以是秒。

步骤S702，客户端获取当前待发送的网络请求。

步骤S703，基于预设打散范围时长，确定当前延时时长。

本步骤中，客户端可以利用随机数系统，基于预设打散范围时长，生成随机数作为当前延时时长，单位为毫秒。

本实施例中，可以利用上述随机数系统，获取随机数random∈[0，duration*1000]，单位为毫秒。

步骤S704，客户端按照当前延时时长进行延时后，发送网络请求至服务端。

本实施例中，客户端在接收到网络请求后，可以按照上述延时时长，延迟random毫秒后，再向客户端进行相应的接口请求。

步骤S705，判断第一预设时间段内客户端请求量是否超过第一预设阈值。

本公开实施例中，上述第一预设时间段可以基于上述打散范围时长duration确定。如，上述预设时间段可以是1/2(duration*1000)毫秒。

本实施例中，服务端可以判断预设时间段内的QPS是否大于第一预设阈值。

步骤S706，服务端向当前负载参数赋值。

本实施例中，若上述预设时间段内的QPS不大于第一预设阈值，即服务端未出现负载过重，那么就可以给负载参数赋值为false。若上述预设时间段内的QPS大于第一预设阈值，即服务端出现负载过重，那么就可以给负载参数赋值为true。

步骤S707，服务端向客户端返回当前负载参数。

步骤S708，客户端基于当前负载参数对当前延时时长进行更新。

本实施例中，客户端基于当前负载参数对当前延时时长进行更新的步骤可以参见方法实施例部分的说明，此处不再赘述。

根据本公开实施例，本公开还提供了一种网络请求的发送装置，应用于客户端，如图8所示，该装置可以包括：

网络请求获取模块810，用于获取当前待发送的网络请求；

延时时长确定模块820，用于确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

网络请求发送模块830，用于按照所述当前延时时长进行延时后，向服务端发送所述网络请求。

本公开实施例中，客户端在获取到待发送的网络请求后，确定当前延时时长，再按照当前延时时长进行延时后，向服务端发送该网络请求。应用本公开实施例，通过对待发送网络请求按照当前延时时长进行延时后，再进行相应的接口请求，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

在本公开的一种实施例中，所述延时时长确定模块820，可以用于利用随机数系统，获取在预设打散范围时长内的随机数，作为当前延时时长；所述随机数以毫秒为单位；或，

预先利用随机数系统，获取在预设打散范围时长内的多个随机数进行保存；

在获取当前待发送的网络请求后，从保存的多个随机数中选择任意一个随机数作为当前延时时长。

在本公开的一种实施例中，上述预设打散范围时长为服务端预先发送至所述客户端的。

在本公开的一种实施例中，基于图8，如图9所示，上述装置还可以包括：

负载参数接收模块930，用于接收服务端发送的当前负载参数；所述当前负载参数表明所述服务端当前是否负载过重，是所述服务端基于第一预设时间段内客户端请求量是否超过第一预设阈值确定的；所述第一预设时间段是基于所述打散范围时长确定的；

负载过重判断模块940，用于基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；

所述网络请求发送模块830，用于按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

根据本公开实施例，本公开还提供了一种网络请求的接收装置，应用于服务端，如图10所示，该装置可以包括：

打散范围时长发送模块1010，用于向客户端发送预设打散范围时长；

网络请求接收模块1020，用于接收客户端发送的网络请求；所述网络请求是：所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送的。

本公开实施例中，本公开实施例中，服务端向客户端发送预设打散范围时长，并接收客户端发送的网络请求，该网络请求是客户端按照基于打散范围时长随机生成的当前延时时长，对待发送的网络请求进行延迟后再发送的。这样，可以将各客户端发送的请求按照时间维度进行平均打散，降低了单位时间内的服务端接收到的网络请求量，避免出现同一时刻有大量客户端向服务端发送请求造成服务端压力过大的情况，更好的保证服务端的正常运行，进而保证网络服务的正常进行。

在本公开的一种实施例中，所述打散范围时长发送模块1010，用于在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

在本公开的一种实施例中，参见图10，上述装置还可以包括：

请求量判断模块1030，用于判断第一预设时间段内客户端请求量是否超过第一预设阈值；其中，所述第一预设时间段小于预设打散范围时长；

负载参数赋值模块1040，用于基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值；其中，所述当前负载参数表明所述服务端当前是否负载过重；

负载参数返回模块1050，用于向所述客户端返回赋值后的当前负载参数；以使所述客户端基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种客户端、一种服务端、一种可读存储介质和一种计算机程序产品。

图11示出了可以用来实施本公开的实施例的示例客户端1100的示意性框图。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图11所示，设备1100包括计算单元1101，其可以根据存储在只读存储器(ROM)1102中的计算机程序或者从存储单元1108加载到随机访问存储器(RAM)1103中的计算机程序，来执行各种适当的动作和处理。在RAM 1103中，还可存储设备1100操作所需的各种程序和数据。计算单元1101、ROM 1102以及RAM 1103通过总线1104彼此相连。输入/输出(I/O)接口1105也连接至总线1104。

设备1100中的多个部件连接至I/O接口1105，包括：输入单元1106，例如键盘、鼠标等；输出单元1107，例如各种类型的显示器、扬声器等；存储单元1108，例如磁盘、光盘等；以及通信单元1109，例如网卡、调制解调器、无线通信收发机等。通信单元1109允许设备1100通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1101可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1101的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1101执行上文所描述的各个方法和处理，例如网络请求的发送方法。例如，在一些实施例中，网络请求的发送方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1108。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1102和/或通信单元1109而被载入和/或安装到设备1100上。当计算机程序加载到RAM 1103并由计算单元1101执行时，可以执行上文描述的网络请求的发送方法的一个或多个步骤。备选地，在其他实施例中，计算单元1101可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行网络请求的发送方法。

图12示出了可以用来实施本公开的实施例的示例服务端1200的示意性框图。

如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(ROM)1202中的计算机程序或者从存储单元1208加载到随机访问存储器(RAM)1203中的计算机程序，来执行各种适当的动作和处理。在RAM 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

设备1200中的多个部件连接至I/O接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元1208，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如网络请求的接收方法。例如，在一些实施例中，网络请求的接收方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1208。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1202和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到RAM 1203并由计算单元1201执行时，可以执行上文描述的网络请求的接收方法的一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行网络请求的接收方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (16)

1.一种网络请求的发送方法，应用于客户端，包括：

获取当前待发送的网络请求；

确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

接收服务端发送的当前负载参数；所述当前负载参数表明所述服务端当前是否负载过重，是所述服务端基于第一预设时间段内客户端请求量是否超过第一预设阈值确定的；所述第一预设时间段是基于所述打散范围时长确定的；

基于所述当前负载参数，确定所述服务端当前是否负载过重；

若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；

若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；

按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

2.根据权利要求1所述的方法，其中，所述确定当前延时时长的步骤，包括：

利用随机数系统，获取在预设打散范围时长内的随机数，作为当前延时时长；所述随机数以毫秒为单位；或，

预先利用随机数系统，获取在预设打散范围时长内的多个随机数进行保存；

在获取当前待发送的网络请求后，从保存的多个随机数中选择任意一个随机数作为当前延时时长。

3.根据权利要求1所述的方法，其中，

所述预设打散范围时长为服务端预先发送至所述客户端的。

4.根据权利要求3所述的方法，其中，

所述第一预设时间段为[0，打散范围时长]，单位为毫秒；

所述将所述当前延时时长延长，得到更新后的当前延时时长的步骤，包括：

若所述当前延时时长在所述第一预设时间段内，且为偶数，则将所述当前延时时长延长所述打散范围时长，作为更新后的当前延时时长；

所述将所述当前延时时长缩短，得到更新后的当前延时时长的步骤，包括：

若所述当前延时时长在第二预设时间段内，且为偶数，则将所述当前延时时长缩短所述打散范围时长，作为更新后的当前延时时长；其中，所述第二预设时间段为[/>打散范围时长，打散范围时长]，单位为毫秒。

5.一种网络请求的接收方法，应用于服务端，包括：

向客户端发送预设打散范围时长；

接收客户端发送的网络请求；所述网络请求是所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

判断第一预设时间段内客户端请求量是否超过第一预设阈值；其中，所述第一预设时间段小于预设打散范围时长；

基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值；其中，所述当前负载参数表明所述服务端当前是否负载过重；

向所述客户端返回赋值后的当前负载参数；以使所述客户端基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

6.根据权利要求5所述的方法，其中，

所述向客户端发送预设打散范围时长的步骤，包括：

在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

7.一种网络请求的发送及接收系统，包括：多个客户端以及服务端；

所述客户端，用于获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；按照所述当前延时时长进行延时后，向服务端发送所述网络请求；

所述服务端，用于向客户端发送预设打散范围时长；接收客户端发送的网络请求；

所述服务端，还用于判断第一预设时间段内客户端请求量是否超过第一预设阈值；其中，所述第一预设时间段小于预设打散范围时长；基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值；向所述客户端返回赋值后的当前负载参数；

所述客户端，还用于接收服务端发送的当前负载参数；基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

8.根据权利要求7所述的系统，其中，

所述服务端，具体用于在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

9.一种网络请求的发送装置，应用于客户端，包括：

网络请求获取模块，用于获取当前待发送的网络请求；

延时时长确定模块，用于确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

负载参数接收模块，用于接收服务端发送的当前负载参数；所述当前负载参数表明所述服务端当前是否负载过重，是所述服务端基于第一预设时间段内客户端请求量是否超过第一预设阈值确定的；所述第一预设时间段是基于所述打散范围时长确定的；

负载过重判断模块，用于基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；

网络请求发送模块，用于按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

10.根据权利要求9所述的装置，其中，所述延时时长确定模块，用于利用随机数系统，获取在预设打散范围时长内的随机数，作为当前延时时长；所述随机数以毫秒为单位；或，

预先利用随机数系统，获取在预设打散范围时长内的多个随机数进行保存；

在获取当前待发送的网络请求后，从保存的多个随机数中选择任意一个随机数作为当前延时时长。

11.根据权利要求9所述的装置，其中，

所述预设打散范围时长为服务端预先发送至所述客户端的。

12.一种网络请求的接收装置，应用于服务端，包括：

打散范围时长发送模块，用于向客户端发送预设打散范围时长；

网络请求接收模块，用于接收客户端发送的网络请求；所述网络请求是：所述客户端获取当前待发送的网络请求；确定当前延时时长；所述延时时长是基于预设的打散范围时长随机生成的；

请求量判断模块，用于判断第一预设时间段内客户端请求量是否超过第一预设阈值；其中，所述第一预设时间段小于预设打散范围时长；

负载参数赋值模块，用于基于所述第一预设时间段内的客户端请求量是否超过所述第一预设阈值的判断结果，向当前负载参数赋值；其中，所述当前负载参数表明所述服务端当前是否负载过重；

负载参数返回模块，用于向所述客户端返回赋值后的当前负载参数；以使所述客户端基于所述当前负载参数，确定所述服务端当前是否负载过重；若确定所述服务端当前负载过重，则将所述当前延时时长延长，得到更新后的当前延时时长；若确定所述服务端当前未出现负载过重，则将所述当前延时时长缩短，得到更新后的当前延时时长；按照所述更新后的当前延时时长进行延时后，向服务端发送所述网络请求。

13.根据权利要求12所述的装置，其中，打散范围时长发送模块，用于在检测到预设第三时间段内客户端请求量超过第二预设阈值后，向所述客户端发送所述预设打散范围时长。

14.一种客户端，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-4中任一项所述的方法。

15.一种服务端，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求5-6中任一项所述的方法。

16.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-4中或5-6中任一项所述的方法。