CN117194827B - Cdn目录刷新的方法及电子设备 - Google Patents

Abstract

本申请公开了CDN目录刷新的方法及电子设备。该方法：接收目录刷新任务并转发给刷新系统；刷新系统根据接收的目录刷新任务，指示配置下发系统生成配置下发任务；将配置下发任务发送至nginx，以更新其中相关目录的版本号；nginx接收用户的URL查询请求，获取对应的源cache_key，根据其和版本号形成目标cache_key并发送给目标缓存；若查询到目标资源，则发送给nginx，若未查询到，则执行回源操作，将回源资源存储下来，并发送给nginx。本申请减少了正则匹配次数，减小了CPU消耗，提升系统的性能，且提高了CDN目录刷新的成功率。

Description

CDN目录刷新的方法及电子设备

技术领域

本申请属于通信技术领域，特别涉及CDN目录刷新的方法及电子设备。

背景技术

当前的CDN目录刷新，并不是真的去在缓存中遍历一个目录下的资源并逐个刷新，而是将这次目录刷新规则记录下来，记录下此次目录刷新命令下发的时间。后续当用户再次请求时，每一条请求都在CDN的缓存中判断此URL与目录刷新规则是否匹配，如果匹配了规则，且缓存的写入时间早于目录刷新规定的时间，则进行此条URL的刷新。

目前的CDN目录刷新是请求触发式，需要缓存将所有的目录刷新的时间都缓存住，逐一进行匹配，每条请求进行多次正则匹配，浪费CPU；并且，由于是请求触发式，CDN设备记录的目录刷新规则有时间限制，如果在目录刷新存在的时间内，某些URL没有被请求，这些URL在CDN的缓存不会被刷新，导致目录刷新可能存在漏网之鱼，可能出现目录刷新不彻底的情况。

针对上述问题，提出本申请中的CDN目录刷新的方法及电子设备。

发明内容

为了解决所述现有技术的不足，本申请提供了一种CDN目录刷新的方法及电子设备，解决现有技术中CDN目录刷新时，需要多次正则匹配，造成CPU等资源浪费，且可能出现目录刷新不彻底的问题。

本申请所要达到的技术效果通过以下方案实现：

第一方面，本申请提供一种CDN目录刷新的方法，所述方法包括：

S1、控制台接收目录刷新任务，并将所述目录刷新任务转发给刷新系统；

S2、所述刷新系统根据接收到的所述目录刷新任务，指示配置下发系统生成配置下发任务；

S3、所述配置下发系统将所述配置下发任务发送至nginx，以更新所述nginx中与所述配置下发任务对应的相关目录的版本号；

S4、所述nginx接收用户的URL查询请求，获取与所述URL查询请求对应的源cache_key，根据所述源cache_key和所述版本号形成目标cache_key，将所述目标cache_key发送给目标缓存，其中，所述目标cache_key包括所述版本号；

S5、所述目标缓存接收所述目标cache_key，并进行查询，如果查询到与所述目标cache_key相匹配的目标资源，则将所述目标资源发送给所述nginx，如果未查询到与所述目标cache_key相匹配的目标资源，则执行相关的回源操作以获取回源资源，将所述回源资源与所述目标cache_key相关联地存储在所述目标缓存中，同时将所述回源资源发送给所述nginx。

在一些实施例中，所述版本号配置有所述配置下发系统给定的时间戳，以保证相关设备的相同目录的所述版本号一致且唯一。

在一些实施例中，所述根据所述源cache_key和所述版本号形成目标cache_key，包括：

在所述源cache_key的字符尾部串连所述版本号，形成所述目标cache_key。

在一些实施例中，所述nginx在接收所述配置下发任务后，执行所述版本号的更新，并向所述配置下发系统反馈任务成功消息，所述配置下发系统根据接收到所述任务成功消息，向所述刷新系统反馈刷新成功消息。

在一些实施例中，所述指示配置下发系统生成配置下发任务，包括：

所述配置下发系统接收所述刷新系统的指示后，执行刷新URL的拆解和目标版本号的生成；

基于拆解后的刷新URL和所述目标版本号生成所述配置下发任务。

在一些实施例中，所述将所述目标cache_key发送给目标缓存，包括：

将所述目标cache_key通过请求头的方式发送给所述目标缓存。

在一些实施例中，在所述控制台接收所述目录刷新任务之前，所述方法还包括：

管理人员在所述控制台提交所述目录刷新任务。

在一些实施例中，所述执行刷新URL的拆解，包括：

拆解出所述刷新URL的域名和路径。

第二方面，本申请提供一种电子设备，所述电子设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现前述任意一项所述的方法。

第三方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现前述任一项所述的方法。

通过本申请提供的CDN目录刷新的方法及电子设备，该方法通过在cache_key后面增加相应的版本号，进而利用携带版本号的cache_key执行缓存查询，减少了缓存的正则匹配次数，减小了CPU消耗，提升系统的性能，且提高了CDN目录刷新的成功率。

附图说明

为了更清楚地说明本申请实施例或现有的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例中的CDN目录刷新的方法的流程图；

图2为本申请一实施例中的CDN目录刷新的方法的关系对应示意图；

图3为本申请一实施例中的电子设备的示意框图。

具体实施方式

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

需要说明的是，除非另外定义，本申请一个或多个实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

本申请的相关解释：

目录刷新：CDN对指定目录下的所有资源进行刷新。

cache_key：CDN的缓存（或者说缓存软件）针对某一个URL的请求资源在缓存中的存储key。

下面结合附图，详细说明本申请的各种非限制性实施方式。

首先，参照图1，对本申请的CDN目录刷新的方法进行详细说明。

本申请实施例提供一种CDN目录刷新的方法，包括：

S1、控制台接收目录刷新任务，并将所述目录刷新任务转发给刷新系统；

S2、所述刷新系统根据接收到的所述目录刷新任务，指示配置下发系统生成配置下发任务；

S3、所述配置下发系统将所述配置下发任务发送至nginx，以更新所述nginx中与所述配置下发任务对应的相关目录的版本号；

S4、所述nginx接收用户的URL查询请求，获取与所述URL查询请求对应的源cache_key，根据所述源cache_key和所述版本号形成目标cache_key，将所述目标cache_key发送给目标缓存，其中，所述目标cache_key包括所述版本号；

S5、所述目标缓存接收所述目标cache_key，并进行查询，如果查询到与所述目标cache_key相匹配的目标资源，则将所述目标资源发送给所述nginx，如果未查询到与所述目标cache_key相匹配的目标资源，则执行相关的回源操作以获取回源资源，将所述回源资源与所述目标cache_key相关联地存储在所述目标缓存中，同时将所述回源资源发送给所述nginx。

具体地，CDN的架构是nginx做业务接入，处理完相关业务后，将请求转发给缓存（cache），以获取缓存内容。

nginx在收到用户请求，处理业务的时候，有一个必不可少的过程就是确定此URL对应在缓存的cache_key；这样转发给缓存后缓存才能命中对应的内容，并将命中的对应内容返回给nginx，nginx响应给用户。

将目录刷新的功能从缓存，前置到nginx接入层，在nginx的接入层处理cache_key的时候，给一个对应的版本号（version），每次目录刷新，其实针对于nginx就是对应目录下的URL的cache_key的版本号做了更新，版本号不同，在存储中cache_key就是不一样的，这样旧内容虽然存在于缓存，但是永远不会被命中，因为cache_key都是新的，缓存响应的肯定是新内容。

示例性地，缓存中如果存储的相关的旧内容长时间不被命中，则可以根据缓存的淘汰规则自然淘汰，比如如果5天或者一个月未被命中，或者命中的次数少于阈值，则进行淘汰，此处为示例性地，本领域技术人员所熟知的其他的淘汰规则均可以应用于此，对此不做限定。

在一些实施例中，所述版本号配置有所述配置下发系统给定的时间戳，以保证相关设备的相同目录的所述版本号一致且唯一。

在一些实施例中，所述根据所述源cache_key和所述版本号形成目标cache_key，包括：

在所述源cache_key的字符尾部串连所述版本号，形成所述目标cache_key。

在一些实施例中，所述nginx在接收所述配置下发任务后，执行所述版本号的更新，并向所述配置下发系统反馈任务成功消息，所述配置下发系统根据接收到的所述任务成功消息，向所述刷新系统反馈刷新成功消息。

在一些实施例中，所述指示配置下发系统生成配置下发任务，包括：

所述配置下发系统接收所述刷新系统的指示后，执行刷新URL的拆解和目标版本号的生成；

基于所述拆解后的刷新URL和所述目标版本号生成所述配置下发任务。

在一些实施例中，所述将所述目标cache_key发送给目标缓存，包括：

将所述目标cache_key通过请求头的方式发送给所述目标缓存。

在一些实施例中，在所述控制台接收所述目录刷新任务之前，所述方法还包括：

管理人员在所述控制台提交所述目录刷新任务。

在一些实施例中，所述执行刷新URL的拆解，包括：

拆解出所述刷新URL的域名和路径。

通过本申请提供的CDN目录刷新的方法，该方法通过在cache_key后面增加相应的版本号，利用携带版本号的cache_key执行缓存查询，减少了缓存的正则匹配次数，减小了CPU消耗，提升系统的性能，且提高了目录刷新的成功率。

下面通过示例对本申请的CDN目录刷新的方法进行详细说明。

如图2所述，本申请的CDN目录刷新的方法包括如下步骤：

1、内容管理员（指上文中的管理人员）在控制台提交目录刷新任务。

控制台收到目录刷新任务后，将任务转发给刷新系统，具体地，可以是通过提交刷新资源实现，例如，提交刷新：http://www.test.com/test/。

2、刷新系统识别到目录刷新，推送刷新任务并联动配置下发系统，生成nginx的配置下发任务，改变对应目录的版本号。

3、配置下发系统下发配置下发至nginx（或者说NGINX服务，这二者指代相同），其中配置下发系统会执行如下操作：

1）刷新URL拆解：拆解域名和路径；

2）生成版本号（例如，1234567），也可以称为目标版本号，与原版本号相对；

3）整合生成nginx配置并下发，其中nginx配置与上文中的配置下发任务指代相同。

4、nginx基于接收到的nginx配置执行更新，并任务成功消息，该消息表示配置下发任务成功执行。

5、配置下发系统在确认nginx配置下发成功后，向刷新系统返回刷新成功消息，该消息表示刷新成功。

6、后续的用户的URL查询请求按照新的nginx配置的版本号，所有的原来的符合路径目录的URL缓存的资源由于版本号变更，在缓存系统里的缓存全部失效；具体逻辑如下：

nginx收到URL查询请求后，根据nginx的相关配置，处理此条URL的业务，例如，nginx需要对cache_key进行相关处理，以从缓存中获取相关的缓存内容。每一次目录刷新，会修改nginx的相关配置，其中版本号使用配置下发系统的时间戳，保证相关所有设备的相同目录的版本号保持一致且唯一。

每次目录刷新都联动配置下发系统，更新nginx的cache_key的相关配置。nginx处理后的cache_key通过header请求头转发给缓存（也指上文中的目标缓存），缓存如果有这个cache_key的资源，则直接响应给nginx，进而nginx响应给用户；如果缓存没有这个cache_key对应的资源，进行相关的回源拉取内容，按照cache_key存储在缓存中，下次有相同cache_key的请求到缓存，缓存会在缓存命中。

具体地，nginx转发给缓存的cache_key是通过请求头的方式，转发给cache一个特定的请求头，这个头的值是一个字符；

示例性地，nginx在确定目标cache_key之后，其通过请求头的方式向目标缓存发送目标cache_key，目标缓存（cache）使用其接收到的目标cache_key，查询其缓存中的各个cache_key，进行匹配和内容获取，如果在缓存中命中了该目标cache_key，则获取该目标cache_key相对应的缓存内容，作为命中结果并返回该命中结果；也就是说，在目标缓存中进行查询的值是请求头中携带的目标cache_key，而不是nginx转发给缓存的URL。nginx转发给cache的目标cache_key的值是由nginx拼接的，本申请在拼接的时候将版本号拼接或者串联在原来cache_key（指上文的源cache_key）的末尾。之前的nginx计算cache_key由于没有版本号，相同的请求cache_key一直不变，来保证相同URL命中相同的缓存，因此只要版本号变更，cache_key就会变化，但是同一个路径下，版本号固定，所以相同URL依旧会命中相同的缓存，而且版本号是针对nginx配置的目录级别的，相同的域名，不同的目录下版本号可能是不一样的。具体的版本号由CDN的配置下发系统决定，通过配置下发的时间戳保证唯一性和全网一致性。

7、用户（或者客户端）在目录刷新的真实访问，在目录刷新内的URL的第一次访问会回源拉取相关内容，并将拉取到的内容存储在缓存中，达到目录刷新的效果。

下面通过另一具体示例进行说明：

以两条URL举例，URL分别为：

http://www.baidu.com/1.txt?a=1；

http://www.baidu.com/2.txt?a=2；

现有的方案是nginx转发给cache的缓存key请求头，如下：

cache_key1：http://www.baidu.com/1.txt?a=1；

cache_key2：http://www.baidu.com/2.txt?a=2。

本申请的方案是nginx转发给cache的缓存key请求头，如下：

cache_key1：http://www.baidu.com/1.txt?a=1selfversion=1234567；

cache_key2：http://www.baidu.com/2.txt?a=2selfversion=1234567。

其中，selfverion= 这部分字符串是固定的；

1234567这部分是nginx配置的版本号（生成方式是配置下发系统的时间戳，全网统一），一旦发生目录刷新，则对应目录的version会发生改变。

示例性地，刷新根目录，所有的版本号都发生更新：

cache_key1：http://www.baidu.com/1.txt?a=1selfversion=1234567；

cache_key2：http://www.baidu.com/2.txt?a=2selfversion=1234567。

因此，Version从1234567变成1234568：

那么后续的nginx转发给cache的缓存key请求头就变成：

cache_key1：http://www.baidu.com/1.txt?a=1selfversion=1234568；

cache_key2：http://www.baidu.com/2.txt?a=2selfversion=1234568。

Version的改变导致前期缓存的URL全部自动失效，进而重新缓存，实现目录刷新。

通过本申请提供的CDN目录刷新的方法，该方法通过在cache_key后面增加相应的版本号，利用携带版本号的cache_key执行缓存查询，减少了缓存的正则匹配次数，减小了CPU消耗，提升系统的性能，且提高了目录刷新的成功率。

需要说明的是，本申请一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

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

基于同一发明构思，与上述任意实施例方法相对应的，本申请还公开一种电子设备；

具体地，图3示出了本实施例所提供的一种CDN目录刷新的方法的电子设备的硬件结构示意图， 该设备可以包括：处理器410、存储器420、输入/输出接口430、通信接口440和总线 450。其中，处理器410、存储器420、输入/输出接口430和通信接口440通过总线450实现彼此之间在设备内部的通信连接。

处理器410可以采用通用的CPU（Central Processing Unit，中央处理器）、微处理器、应用专用集成电路（Application Specific Integrated Circuit，ASIC）、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案。

存储器420可以采用ROM（Read Only Memory，只读存储器）、RAM（Random AccessMemory，随机存取存储器）、静态存储设备，动态存储设备等形式实现。存储器420可以存储操作系统和其他应用程序，在通过软件或者固件来实现本申请实施例所提供的技术方案时，相关的程序代码保存在存储器420中，并由处理器410来调用执行。

输入/输出接口430用于连接输入/输出模块，以实现信息输入及输出。输入/输出模块可以作为组件配置在设备中（图中未示出），也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口440用于连接通信模块（图中未示出），以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式（例如，USB、网线等）实现通信，也可以通过无线方式（例如，移动网络、WIFI、蓝牙等）实现通信。

总线450包括一通路，在设备的各个组件（例如，处理器410、存储器420、输入/输出接口430和通信接口440）之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器410、存储器420、输入/输出接口430、通信接口440以及总线450，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的CDN目录刷新的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本申请一个或多个实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的CDN目录刷新的方法。

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

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的CDN目录刷新的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围（包括权利要求）被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本申请一个或多个实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路（IC）芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以避免使本申请一个或多个实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请一个或多个实施例的平台的（即，这些细节应当完全处于本领域技术人员的理解范围内）。在阐述了具体细节（例如，电路）以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请一个或多个实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构（例如，动态RAM（DRAM））可以使用所讨论的实施例。

本申请一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种CDN目录刷新的方法，其特征在于，所述方法包括：

S1、控制台接收目录刷新任务，并将所述目录刷新任务转发给刷新系统；

S2、所述刷新系统根据接收到的所述目录刷新任务，指示配置下发系统生成配置下发任务；

S3、所述配置下发系统将所述配置下发任务发送至nginx，以更新所述nginx中与所述配置下发任务对应的相关目录的版本号；

S4、所述nginx接收用户的URL查询请求，获取与所述URL查询请求对应的源cache_key，根据所述源cache_key和所述版本号形成目标cache_key，将所述目标cache_key发送给目标缓存，其中，所述目标cache_key包括所述版本号；

S5、所述目标缓存接收所述目标cache_key，并进行查询，如果查询到与所述目标cache_key相匹配的目标资源，则将所述目标资源发送给所述nginx，如果未查询到与所述目标cache_key相匹配的目标资源，则执行相关的回源操作以获取回源资源，将所述回源资源与所述目标cache_key相关联地存储在所述目标缓存中，同时将所述回源资源发送给所述nginx。

2.根据权利要求1所述的CDN目录刷新的方法，其特征在于，所述版本号配置有所述配置下发系统给定的时间戳，以保证相关设备的相同目录的所述版本号一致且唯一。

3.根据权利要求1或2所述的CDN目录刷新的方法，其特征在于，所述根据所述源cache_key和所述版本号形成目标cache_key，包括：

在所述源cache_key的字符尾部串连所述版本号，形成所述目标cache_key。

4.根据权利要求3所述的CDN目录刷新的方法，其特征在于，所述nginx在接收所述配置下发任务后，执行所述版本号的更新，并向所述配置下发系统反馈任务成功消息，所述配置下发系统根据接收到所述任务成功消息，向所述刷新系统反馈刷新成功消息。

5.根据权利要求1所述的CDN目录刷新的方法，其特征在于，所述指示配置下发系统生成配置下发任务，包括：

所述配置下发系统接收所述刷新系统的指示后，执行刷新URL的拆解和目标版本号的生成；

基于拆解后的刷新URL和所述目标版本号生成所述配置下发任务。

6.根据权利要求1所述的CDN目录刷新的方法，其特征在于，所述将所述目标cache_key发送给目标缓存，包括：

将所述目标cache_key通过请求头的方式发送给所述目标缓存。

7.根据权利要求1所述的CDN目录刷新的方法，其特征在于，在所述控制台接收所述目录刷新任务之前，所述方法还包括：

管理人员在所述控制台提交所述目录刷新任务。

8.根据权利要求5所述的CDN目录刷新的方法，其特征在于，所述执行刷新URL的拆解，包括：

拆解出所述刷新URL的域名和路径。

9.一种电子设备，所述电子设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至8中任意一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至8任意一项所述的方法。