CN114979025B - 资源刷新方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种资源刷新方法、装置、设备及可读存储介质，调度中心向边缘节点发送用于请求刷新目标域名下的资源的刷新请求。边缘节点接收到刷新请求后，判断用于存储已缓存的资源中每个资源的域名的索引列表中是否存在目标域名。当索引列表中存在目标域名时，边缘节点刷新目标域名下的资源。当索引列表中不存在目标域名时，边缘节点直接反馈刷新完成响应。采用该种方案，边缘节点维护索引列表，索引列表按照域名粒度进行存储、且仅存储边缘节点已缓存的资源的域名，最多只会有几万条记录，是传统精准刷新方式数据量的万分之一，极大程度上降低了匹配量和耗时的同时，减少了空刷新率、实现快速刷新、且不影响用户的正常访问。

Description

资源刷新方法、装置、设备及可读存储介质

技术领域

本申请涉及互联网技术领域，特别涉及一种资源刷新方法、装置、设备及可读存储介质。

背景技术

内容分发网络(Content Delivery Network，CDN)是建立并覆盖在承载网之上、由分布在不同区域的边缘节点组成的分布式网络。

与传统以网页服务器(Web Server)为中心的数据传输模式不同的是，CDN将源站的资源缓存到分布于不同区域的边缘节点，使用户可以就近获取所需资源，提高访问速度和成功率的同时，降低源站压力。其中，资源包括网页、图片、音频、视频等。当资源提供方对源站的资源进行刷新时，需要对已分发至边缘节点的资源进行刷新。刷新过程中，根据需要刷新的资源对应的域名，从所有边缘节点中确定出该域名覆盖范围内的边缘节点，然后这些边缘节点进行资源刷新。

然而，并不是域名覆盖范围内的所有边缘节点上都缓存了需要刷新的资源。对于没有缓存需要刷新的资源的边缘节点而言，就进行了一次空刷新。空刷新消耗边缘节点的部分性能，导致边缘节点无法正常响应用户访问等。

发明内容

本申请提供一种资源刷新方法、装置、设备及可读存储介质，通过精准刷新，降低资源刷新带来的性能消耗，实现快速刷新的同时，不影响用户的正常访问。

第一方面，本申请实施例提供一种资源刷新方法，应用于边缘节点，所述方法包括：

接收来自调度中心的刷新请求，所述刷新请求用于请求刷新目标域名下的资源；

确定索引列表中是否存在所述目标域名，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名；

当所述索引列表中存在所述目标域名时，刷新所述目标域名下的资源。

第二方面，本申请实施例提供一种资源刷新方法，应用于调度中心，所述方法包括：

按批次生成刷新请求以得到第二集合，所述第二集合中的各刷新请求用于请求刷新目标域名下的不同资源；

向网络中的各边缘节点发送所述第二集合中的各刷新请求。

第三方面，本申请实施例提供一种资源刷新装置，集成在边缘节点，所述装置包括：

收发模块，用于接收来自调度中心的刷新请求，所述刷新请求用于请求刷新目标域名下的资源；

处理模块，用于确定索引列表中是否存在所述目标域名，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名；

刷新模块，用于当所述索引列表中存在所述目标域名时，刷新所述目标域名下的资源。

第四方面，本申请实施例提供一种资源刷新装置，集成在调度中心，所述装置包括：

处理模块，用于按批次生成刷新请求以得到第二集合，所述第二集合中的各刷新请求用于请求刷新目标域名下的不同资源；

收发模块，用于向网络中的各边缘节点发送所述第二集合中的各刷新请求。

第五方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时使得所述电子设备实现如上第一方面或第一方面各种可能的实现方式所述的方法。

第六方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时使得所述电子设备实现如上第二方面或第二方面各种可能的实现方式所述的方法。

第七方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令在被处理器执行时用于实现如上第一方面或第一方面各种可能的实现方式所述的方法。

第八方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令在被处理器执行时用于实现如上第二方面或第二方面各种可能的实现方式所述的方法。

第九方面，本申请实施例提供一种包含计算程序的计算机程序产品，所述计算机程序被处理器执行时实现如上第一方面或第一方面各种可能的实现方式所述的方法。

第十方面，本申请实施例提供一种包含计算程序的计算机程序产品，所述计算机程序被处理器执行时实现如上第二方面或第二方面各种可能的实现方式所述的方法。

本申请实施例提供的资源刷新方法、装置、设备及可读存储介质，调度中心向边缘节点发送用于请求刷新目标域名下的资源的刷新请求。边缘节点接收到刷新请求后，判断用于存储已缓存的资源中每个资源的域名的索引列表中是否存在目标域名。当索引列表中存在目标域名时，边缘节点刷新目标域名下的资源。当索引列表中不存在目标域名时，边缘节点直接反馈刷新完成响应。采用该种方案，通过边缘节点维护索引列表，索引列表按照域名粒度进行存储、且仅存储边缘节点已缓存的资源的域名，最多只会有几万条记录，是传统精准刷新方式数据量的万分之一，极大程度上降低了匹配量和耗时的同时，减少了空刷新率、实现快速刷新、且不影响用户的正常访问。而且，无需建立额外的索引中心，每个边缘节点维护自己的索引列表，本机快速判断、快速写入，不需要上报，不会增加网络开销和耗时。同时，调度中心下发刷新请求时无需查询索引中心，而是向所有的边缘节点下发，不存在网络开销和查询耗时，能够保证时效性。

附图说明

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

图1是本申请实施例提供的资源刷新方法所适用的网络架构示意图；

图2是本申请实施例提供的资源刷新方法的流程图；

图3是本申请实施例提供的资源刷新方法的另一个流程图；

图4是本申请实施例提供的刷新方法的另一个流程图；

图5为本申请实施例提供的一种资源刷新装置的示意图；

图6为本申请实施例提供的一种资源刷新装置的示意图；

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

随着互联网的发展，网络流量迅速增长，这对网络服务质量提出了挑战。为了改善互联网服务质量，加快网络访问速度，内容分发网络(Content Delivery Network，CDN)逐渐得到应用。CDN目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的边缘节点，使用户可以就近取得所需的内容，减少延迟，解决Internet网络拥挤的状况，还能降低源站压力。

当资源提供方更新或删除源站的资源时，边缘节点也需要对资源进行刷新，以使得用户从边缘节点获取资源时，能够获取到最新资源。边缘节点的资源刷新也称之为缓存刷新等。资源刷新需要保证高效性和准确性。高效性是指边缘节点在秒级内刷新完成资源刷新；准确性是指所有已缓存目标资源的边缘节点都要进行资源刷新，即使一个边缘节点当前没有向用户提供服务，但是该边缘节点上已缓存目标资源，则该边缘节点也需要进行资源刷新，目标资源是源站更新的资源。这意味着大量的边缘节点需要进行资源刷新，这个量级是几千或者上万台边缘节点。

同时，资源提供方很多，一个资源提供方刷新的资源也很多，资源提供方的刷新指令到达资源刷新端，由资源刷新端将大量的资源刷新请求下发给边缘节点，边缘节点每秒钟要处理几千条刷新请求。大量的边缘节点、大量的刷新任务的情况下，边缘节点既要快速处理刷新请求，又要保证边缘节点的性能，不能影响用户的正常访问。

为了保证所有已缓存目标资源的边缘节点都执行资源刷新且兼顾高效性，传统的处理方式是：域名覆盖原则，即确定目标资源对应的域名，然后从所有边缘节点中确定出该域名覆盖范围内的边缘节点，这些边缘节点进行资源刷新。这样做的好处是：假设一个边缘节点是主节点，本来由主节点向用户提供服务，但是由于网络或其他问题，导致用户切换至备节点。这时候，主节点虽然当前不再提供服务，但是用户曾经访问过主节点，主节点上已缓存目标资源，因此主节点也需要进行资源刷新。

基于域名覆盖原则，资源刷新端向全域名覆盖范围内的全部边缘节点下发刷新请求，各边缘节点进行资源刷新。然而，并不是域名覆盖范围内的所有边缘节点上都缓存了目标资源。例如，预先配置主节点和备节点都是域名覆盖范围内的节点，但是一直由主节点提供服务，备节点未向用户提供服务，备节点上并没有缓存目标资源。倘若基于域名覆盖范围进行资源刷新，则备节点执行空刷新，消耗了备节点的部分性能。对于其他域名而言，备节点可能是主节点，消耗性能导致备节点无法向用户提供服务等。

为解决域名覆盖原则导致的空刷新，业界已出现一些精准刷新方法。该种刷新方法中，引入一个索引中心，各边缘节点将IP和已缓存的资源上报给索引中心，索引中心建立IP和资源的映射表。需要刷新时，根据目标资源查询映射表，以确定出需要刷新的边缘节点列表。然后，向列表中的边缘节点发送刷新请求。由于不同资源的统一资源定位符(UniformResource Locator，URL)不同，使得映射表中的记录是URL级别的记录。

然而，这种精准刷新方法只适合小规模的CDN。对于大规模的CDN而言，边缘节点数量庞大，每台边缘节点上缓存几千万的资源，导致索引中心要保存千亿级别的数据。一旦查询失败，就会使得部分边缘节点没有进行资源刷新。倘若用户这部分边缘节点请求资源，则容易请求到旧资源。另外，边缘节点向索引中心上报IP和资源、索引中心在映射表中写入IP和资源的对应关系都存在延迟性，导致边缘节点难以在秒级内完成资源刷新，无法保证资源刷新的高效性。

基于此，本申请实施例提供一种资源刷新方法，通过边缘节点维护索引列表，索引列表按照域名粒度进行存储、且仅存储边缘节点已缓存的资源的域名，极大程度上降低了匹配量的同时，减少了空刷新率，实现快速刷新的同时，不影响用户的正常访问。

图1是本申请实施例提供的资源刷新方法所适用的网络架构示意图。请参照图1，该网络架构包括：边缘节点11、调度中心12、源站13、用户端14和资源提供方15。需要说明的是，图1中虽然只绘示了一个边缘节点11，实际应用中，可以为一个或多个边缘节点11。以下以多个边缘节点11为例进行说明。

请参照图1，资源提供方15和边缘节点11分别与源站13建立网络连接。源站13也称之为源站服务器、源节点等，用于存储并向边缘节点11分发资源。和用户端14分别与边缘节点11建立网络连接。

资源提供方15对源站13上的资源进行删除、更新等，并向调度中心12发送资源刷新指令。调度中心12接收到资源刷新指令后，向各个边缘节点11发送刷新请求，该刷新请求携带目标域名，请求刷新目标域名下的资源。

每个边缘节点11预先创建所有列表，该索引列表中存储边缘节点11已缓存的多个资源中每个资源的域名。边缘节点11接收到刷新请求后，判断刷新请求指示的目标域名是否包含在索引列表中。若索引列表中存在目标域名，则对目标域名下的资源进行刷新。

本申请实施例提供的资源刷新方法和上述基于域名覆盖原则的不同之处在于：本申请实施例中，向所有的边缘节点11下发刷新请求，由边缘节点11根据自身维护的索引列表确定是否刷新资源。而基于域名覆盖原则中，并没有向所有的边缘节点11下发刷新请求，而是仅向域名覆盖范围内的边缘节点11发送刷新请求。

用户端14向边缘节点11发送访问请求。边缘节点11接收到访问请求后，若已缓存用户端14请求的资源，则向用户端14返回资源。倘若边缘节点11未缓存用户端14所请求的资源，则从源站13获取资源并缓存，同时将获取到的资源返回给用户端14。

应当理解的是，图1中的边缘节点11、调度中心12、源站13、用户端14和资源提供方15的数量仅仅是示意性的。实际实现中，根据实际需求部署任意数量的边缘节点11、调度中心12、源站13、用户端14和资源提供方15。

下面，基于图1所示网络架构，对本申请实施例提供的资源刷新方法进行详细说明。示例性的，请参照图2。图2是本申请实施例提供的资源刷新方法的流程图。本实施例是从边缘节点和调度中心交互的角度进行说明，本实施例包括：

201、调度中心生成用于请求刷新目标域名下的资源的刷新请求。

当资源提供方更新或删除源站上的资源时，资源提供方向调度中心发送资源刷新指令。调度中心接收到资源刷新指令后，生成刷新请求，该刷新请求携带目标域名。例如，资源请求方对源站的一个图片进行更新，图片名称为image，位于test目录下，则刷新请求体现为：http://test.com/test/image.jpg。其中，“test.com”表示目标域名，“test”表示目标资源在源站中的目录信息，“image.jpg”表示目标资源的资源名称和格式。

202、调度中心向多个边缘节点发送所述刷新请求。

调度中心生成刷新请求后，向CDN中的各个边缘节点发送刷新请求。相应的，各边缘节点接收刷新请求。

本申请实施例中，调度中心下发刷新请求时，无需如传统的引入索引中心的刷新方法中，查询索引中心以确定出需要执行刷新的边缘节点列表。而是向所有的边缘节点下发刷新请求，由边缘节点自行确定是否执行刷新。如此一来，由于不存上层的网络开销和查询，极大程度上保证了时效性。

203、边缘节点确定索引列表中是否存在所述目标域名，当索引列表中存在目标域名时，边缘节点执行步骤204；当索引列表中不存在目标域名时，边缘节点执行步骤205。其中，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名。

示例性的，每个边缘节点预先创建一个索引列表并实时更新维护。索引列表中存储边缘节点已缓存的资源中各资源的域名或者域名对应的哈希值等。

初始时，索引列表为空，后续边缘节点每次接收到来自终端设备，即用户端的业务请求后，判断已缓存的资源中是否存在业务请求所请求的资源。当已缓存的资源中没有业务请求所请求的资源时，从源站获取所述业务请求所请求的资源并缓存，响应用户端的同时根据所述业务请求所请求的资源的域名更新所述索引列表。

例如，边缘节点已缓存资源a、资源b和资源c，域名分别为域名1、域名2和域名3，则索引列表中存储域名1、域名2和域名3。用户向边缘节点发起访问请求，请求访问域名b，则边缘节点直接将资源b响应给用户。若用户请求访问资源d，边缘节点未缓存资源d，则边缘节点从源站获取资源d并缓存，将资源d响应给用户。同时，边缘节点将资源d的域名4写入索引列表。

本申请实施例中，索引列表中可以存储域名或域名的哈希值。当索引列表中存储哈希值时，边缘节点每次接收到刷新请求，提取目标域名并计算哈希值，根据哈希值与索引列表中已存储的哈希值进行匹配。同理，边缘节点每次更新索引列表时，计算出新的域名的哈希值并写入索引列表。

采用该种方案，通过实时更新索引列表，确保资源刷新的准确性。

对于每一个边缘节点而言，由于索引列表中存储该边缘节点已缓存的资源的域名，而不是每个资源的URL。因此，索引列表中的每条记录是域名粒度的记录，极大程度上减少了索引列表中的记录的数量。而且，虽然预先配置边缘节点的域名是几万个，但是由于索引列表中只存储边缘节点已缓存的资源的域名，因此，索引列表中可能只有几千条记录。例如，预先为边缘节点配置了20000个域名，但是用户已请求访问的资源的域名是其中的5000个，则索引列表中存储5000个域名。

边缘节点每次接收到刷新请求后，仅在该5000个域名中进行匹配，加快匹配速度。以域名1为例、CDN网络中有1万台边缘节点、5000个边缘节点配置了域名1、2000台边缘节点已缓存目标资源为例，本申请实施例中，调度中心向1万台边缘节点发送刷新请求，仅2000台边缘节点进行资源刷新。而传统的基于域名覆盖原则，5000个边缘节点需要执行资源刷新。

由于一个域名下可能有多个不同的资源，当一个边缘节点的索引列表中存储目标域名时，该边缘节点可能并未缓存目标资源。继续沿用上述的例子，假设目标资源的URL是http://test.com/test/image1.jpg，2000台边缘节点中的1000台边缘节点已缓存资源image1，另外1000台边缘节点已缓存资源image2，image2的URL是http://test.com/test/image2.jpg。image1和image2的域名相同，均是test.com。基于本申请实施例，2000台边缘节点执行资源刷新，其中1000台是空刷新。但是，倘若采用基于域名覆盖原则，则空刷新的边缘节点多达4000台。

由此可见，本申请实施例中，索引列表按照域名粒度进行存储、且仅存储边缘节点已缓存的资源的域名，极大程度上降低了匹配量的同时，减少了空刷新率，确保边缘节点高效刷新的同时，保证大部分边缘节点的性能不受影响。

204、当所述索引列表中存在所述目标域名时，边缘节点刷新所述目标域名下的资源。

当刷新请求指示更新目标资源时，边缘节点根据刷新请求指示的目录、目标资源的名称等，从源站获取最新版本的目标资源，删除旧版本的目标资源并缓存最新版本的目标资源。

当刷新请求指示删除目标资源时，边缘节点根据刷新请求指示的资源名称等，从已缓存的资源中删除目标资源。

刷新完毕后，边缘节点向调度中心反馈刷新完成响应。

205、边缘节点向调度中心反馈刷新完成响应。

示例性的，如果索引列表中不存在目标域名，则边缘节点直接向调度中心反馈刷新完成响应，以结束本次刷新。

本申请实施例提供的资源刷新方法，调度中心向边缘节点发送用于请求刷新目标域名下的资源的刷新请求。边缘节点接收到刷新请求后，判断用于存储已缓存的资源中每个资源的域名的索引列表中是否存在目标域名。当索引列表中存在目标域名时，边缘节点刷新目标域名下的资源。当索引列表中不存在目标域名时，边缘节点直接反馈刷新完成响应。采用该种方案，通过边缘节点维护索引列表，索引列表按照域名粒度进行存储、且仅存储边缘节点已缓存的资源的域名，最多只会有几万条记录，是传统精准刷新方式数据量的万分之一，极大程度上降低了匹配量和耗时的同时，减少了空刷新率、实现快速刷新、且不影响用户的正常访问。而且，无需建立额外的索引中心，每个边缘节点维护自己的索引列表，本机快速判断、快速写入，不需要上报，不会增加网络开销和耗时。同时，调度中心下发刷新请求时无需查询索引中心，而是向所有的边缘节点下发，不存在网络开销和查询耗时，能够保证时效性。

可选的，上述实施例中，大多数情况下，边缘节点已缓存的资源中的一个资源对应一个域名，多个资源可能对应同一个域名。但是，还有一种情况是：一个资源对应多个域名。这时候，边缘节点需要将多个域名中的每个域名都存储在索引列表中。

例如，一个资源为imageX，对应域名1、域名2和域名3。也就是说，用户想要访问imageX时，可以通过域名1、域名2或域名3中的任意一个域名访问。同理，资源提供方更新imageX时，可通过域名1、域名2或域名3中的任意一个域名更新。倘若索引列表中仅存在这3个域名中的任意一个域名，比如域名2，则很有可能出现资源提供方已更新imageX、但是边缘节点未刷新，导致用户端访问不到最新版本的imageX的问题。比如，边缘节点的索引列表中存在域名2，资源提供方通过域名3修改imageX。边缘节点接收到刷新请求指示的目标域名为域名3，但是由于索引列表中不存在域名3，因此，边缘节点认为未缓存imagex,直接反馈刷新完成响应。

而本申请实施例中，边缘节点的索引列表中同时存储域名1、域名2和域名3，边缘节点接收到刷新请求指示的目标域名为域名3，由于索引列表中存在域名3，因此，边缘节点对imageX执行刷新。

采用该种方案，当一个资源对应多个域名时，将该资源的全部域名均存储在索引列表中，能够确保资源刷新的准确性。

可选的，上述实施例中，当所述索引列表中不存在所述目标域名时，后续预设时长内，每次接收到用于请求刷新所述目标域名下的资源的刷新请求后，向所述调度中心发送刷新完成响应。

示例性的，当边缘节点的索引列表中不存在目标域名时，说明边缘节点未缓存目标域名下的任何一个资源。因此，边缘节点一旦确定出索引列表中没有目标域名，则未来预设时长内，比如1分钟、2分钟内，每次接收到携带目标域名的刷新请求后，不执行资源刷新而是直接向调度中心反馈刷新完成响应。

采用该种方案，倘若索引列表中不存在目标域名，则未来预设时长内，针对该目标域名的刷新请求，边缘节点都反馈刷新完成，没有空刷新不影响边缘节点的性能，且反馈速度快。

可选的，上述实施例中，边缘节点匹配索引列表和目标域名时，除了索引列表中存在目标域名、索引列表中不存在目标域名外，还有一种情况：边缘节点无法确定出索引列表中是否存在目标域名。这时候，边缘节点默认索引列表中存在目标域名，并对目标域名下的资源进行刷新。

示例性的，边缘节点判断已缓存的资源中是否存在目标域名下的资源。当边缘节点已缓存的资源中存在目标域名下的资源时，刷新该资源。当边缘节点已缓存的资源中不存在目标域名下的资源时，边缘节点反馈刷新完成响应。

例如，刷新请求携带指示的目标资源时video3，当前访问边缘节点的用户端比较多，边缘节点的内存等被占用，导致边缘节点无法去查询索引列表。于是，边缘节点根据目标资源的资源名称、类别等检索已缓存的资源，判断已缓存的资源中是否存在目标资源。当已缓存的资源中存在目标资源时，边缘节点根据刷新请求指示的路径、名称等从源站获取最新版本的目标资源并更新。当以缓存的资源中不存在目标资源时，边缘节点向调度中心反馈刷新完成响应。

采用该种方案，一旦边缘节点查询索引列表失败，则默认资源刷新，保证不会漏掉需要刷新的资源，实现提高业务可靠性的目的。

可选的，上述实施例中，当所述索引列表中不存在所述目标域名时，后续预设时长内，每次接收到用于请求刷新所述目标域名下的资源的刷新请求后，向所述调度中心发送刷新完成响应。

示例性的，用户端不断向边缘节点发起业务请求以请求业务，一旦边缘节点未缓存用户请求的资源，则边缘节点向源站获取资源并缓存。之后，边缘节点更新索引列表。因此，索引列表并不是一成不变的，而是根据边缘节点已缓存的资源的变化而变化。

为了防止资源刷新不彻底，预设时长后，边缘节点再次接收到用于请求刷新所述目标域名下的资源的刷新请求时，需要重新判断索引列表中是否存在所述目标域名。示例性的，请参照图3，图3是本申请实施例提供的资源刷新方法的另一个流程图。本实施例包括：

301、边缘节点确定索引列表中不存在目标域名。

302、边缘节点再次接收到用于请求刷新目标域名下的资源的刷新请求。

303、边缘节点确定时间间隔是否超过预设时长。若时间间隔小预设时长，则执行步骤304；若时间间隔大于或等于预设时长，则执行步骤305。

示例性的，边缘节点确定第一时间点和第二时间点之间的时间间隔是否大于预设时长。其中，第一时间点边缘节点最近一次确定出索引列表中不存在目标域名的时间点，第二时间点是边缘节点本次接收到刷新请求的时间点。

304、向所述调度中心发送刷新完成响应。

示例性的，边缘节点不执行资源刷新，而是直接向调度中心发送刷新完成响应。

305、确定所述索引列表中是否存在所述目标域名，若索引列表中存在目标域名，则执行步骤306；若索引列表中不存在目标域名，则执行步骤304。

当时间间隔大于或等于预设时长时，这段时间间隔内，边缘节点很有可能已经更新了索引列表。因此，需要重新判断索引列表中是否存在目标域名，以防止有些需要刷新的资源未更新。

306、追溯所述预设时长内所述边缘节点接收到的刷新请求以得到第一集合。

307、刷新所述第一集合内各刷新请求中每个刷新请求所请求刷新的资源。

示例性的，假设第一时间点为15:54:00(15点54分00秒)，预设时长为1分钟，第二时间点为15:55:00，则对于这两个时间点之间的、携带目标域名的刷新请求，边缘节点均反馈刷新完成响应。但是第二时间点之后，比如15:55:01秒，边缘节点再次接收到携带目标域名的刷新请求，这时候，边缘节点得重新判断索引列表中是否存在目标域名。

以索引列表中预先存储的域名包括域名1、域名2和域名3，刷新请求携带的目标域名为域名4为例，假设15:54:30-15:54:55这段时间内，用户端请求域名4下的资源e、资源f和资源g，由于边缘节点并未缓存资源e、资源f和资源g，因此，边缘节点从源站获取这些资源并缓存，同时在索引列表中增加域名4。而且，15:54:00-15:55:00这段时间内，调度中心下发的刷新请求用于刷新目标域名下的资源e和资源f。

15:55:00时，边缘节点再次接收到携带目标域名的刷新请求后，发现索引列表中存在目标域名，于是追溯15:54:00-15:55:00这段时间内，边缘节点接收到的刷新请求以得到第一集合，显然，该第一集合中的刷新请求用于请求刷新资源e和资源f。之后，边缘节点刷新资源e和资源f。

采用该种方案，预设时长后，倘若索引列表中存在目标域名，则赘述过去预设时长内的刷新请求，以对这些刷新请求对应的资源进行刷新，确保不遗漏需要刷新的资源，实现提高业务可靠性的目的。

可选的，上述实施例中，调度中心生成刷新请求的过程中，按批次生成刷新请求以得到第二集合，所述第二集合中的各刷新请求用于请求刷新目标域名下的不同资源，并向网络中的各边缘节点发送所述第二集合中的各刷新请求。

示例性的，调度中心按批次下发刷新请求，一个批次的刷新请求中各刷新请求指示同一个目标域名，不同刷新请求用于刷新目标域名下的不同资源。例如，两个刷新请求分别为：http://test.com/test/video1.jpg、http://test.com/test/video2.jpg。这两个刷新请求属于同一个批次，即均是第二集合中的刷新请求。该两个刷新请求分别用于请求刷新video1和video2。属于同一个批次的刷新请求携带相同的批次号。

按批次下发刷新请求时，调度中心依次向所有边缘节点发送一个批次中的各个刷新请求，相邻两个刷新请求之间的时间间隔例如是毫秒级别的间隔等，本申请实施例并不限制。

图4是本申请实施例提供的刷新方法的另一个流程图。本实施例包括：

401、边缘节点判断本次接收到的刷新请求与之前接收到的刷新请求是否属于同一个批次，若不是同一个批次，则执行步骤402；若是同一个批次，则执行步骤405。

对于边缘节点而言，每次接收到刷新请求后，判断该刷新请求与之前接收到的刷新请求是否属于同一个批次。例如，每个刷新请求携带批次号，若本次接收到的刷新请求与上次接收到的刷新请求携带同一个批次号，则表示这两个刷新请求属于同一个批次。若本次接收到的刷新请求与上次接收到的刷新请求携带的批次号不同，则表示该两个刷新请求不是同一个批次。

402、确定所述索引列表中是否存在所述刷新请求携带的目标域名，以得到判断结果。若刷新请求携带目标域名，则执行步骤403；若刷新请求未携带目标域名，则执行步骤404。

403、当所述判断结果指示所述索引列表中存在所述目标域名时，确定第二集合中所有的刷新请求都用于刷新所述目标域名下的资源。

示例性的，边缘节点后续每次接收到携带相同批次号的刷新请求后，不再执行步骤402，而是默认执行资源刷新。

404、当所述判断结果指示所述索引列表中不存在所述目标域名时，确定所述第二集合中所有的刷新请求都不是用于刷新所述目标域名下的资源。也就是说，边缘节点每次接收到第二集合中的其他刷新请求后，直接反馈刷新成功而不执行资源刷新。

示例性的，边缘节点后续每次接收到携带相同批次号的刷新请求后，不再执行步骤402，而是默认不执行资源刷新。

405、根据之前接收到的刷新请求的判断结果确定是否执行资源刷新。

具体可参见步骤403和步骤404，此处不再赘述。

采用该种方案，调度中心按批次下发刷新请求，针对每个批次的刷新请求，边缘节点仅判断一次目标域名是否属于索引列表从而得到判断结果，其他刷新请求根据判断结果处理，极大程度上保证了刷新的时效性且不影响用户业务。

可选的，上述实施例中，边缘节点将所述索引列表存储在所述边缘节点的非易失性存储器中并定期更新。

示例性的，边缘节点工作过程中，索引列表位于内存中。为了避免断电后，比如边缘节点重启、边缘节点上的服务重启等导致索引列表丢失。边缘节点将索引列表存储在非易失性存储器并定期更新。例如，初始创建好索引列表后，当索引列表中的记录超过预设数量或创建好索引表经过预设时间长度，比如2小时等，边缘节点将索引列表存储在非易失性存储器。后续每个2小时，用最新版本的索引列表替换旧版本的索引列表。或者，每次索引列表中新增域名时，用最新版本的索引列表替换旧版本的索引列表。

采用该种方案，通过定期将索引列表存储并更新至非易失性存储器，避免边缘节重启等导致索引列表丢失，确保资源刷新的时效性和准确性。

可选的，上述实施例中，当边缘节点重启或边缘节点提供的服务重启时，边缘节点从非易失性存储器读取索引列表并加载至内存。之后，边缘节点接收来自调度中心的刷新请求并进行资源刷新。

示例性的，边缘节点定期对索引列表进行落盘存储，即定期将索引列表存储并更新至非易失性存储器。遇上边缘节点重启或边缘节点提供的服务重启时，从非易失性存储器读取所述索引列表并加载至内存。加载完索引列表后，边缘节点重启成功，或者，边缘节点提供的服务启动成功。之后，边缘节点才能对外提供服务。例如，接收来自调度中心的刷新请求进行资源刷新；再如，接收用户端的访问请求并响应用户端。

采用该种方案，边缘节点只有在加载完索引列表后才对外提供服务，确保业务可靠性。

可选的，上述实施例中，若所述索引列表未成功存储在所述非易失性存储器，边缘节点根据配置文件生成索引列表，并将所述索引列表加载至内存。之后，边缘节点才能对外提供服务。其中，所述配置文件指示配置给所述边缘节点的域名。

示例性的，边缘节点定期存储并更新索引列表时，可能会发生未成功存储索引列表的情况。这时候，边缘节点自动根据预先存储的配置文件生成索引列表，并将索引列表加载在内容。例如，假设预先为边缘节点配置了20000个域名，但是用户已请求访问的资源的域名是其中的5000个，则索引列表中存储5000个域名。但是，由于存储失败，这时候，边缘节点将20000个域名均存储在索引列表中，虽然很有可能会发生空刷新，但是不会漏掉对需要刷新的资源的刷新。后续当边缘节点判断出未缓存某个域名下的资源时，则从索引列表中删除该域名。

采用该种方案，当落盘异常时，边缘节点将配置给自身的所有域名都写入索引列表，确保资源刷新的准确性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请实施例提供的一种资源刷新装置的示意图。该资源刷新装置500包括：收发模块51、处理模块52和刷新模块53。

收发模块51，用于接收来自调度中心的刷新请求，所述刷新请求用于请求刷新目标域名下的资源；

处理模块52，用于确定索引列表中是否存在所述目标域名，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名；

刷新模块53，用于当所述索引列表中存在所述目标域名时，刷新所述目标域名下的资源。

一种可行的实现方式中，所述收发模块51，还用于当所述索引列表中不存在所述目标域名时，后续预设时长内，每次接收到用于请求刷新所述目标域名下的资源的刷新请求后，向所述调度中心发送刷新完成响应。

一种可行的实现方式中，所述收发模块51，还用于预设时长后，再次接收用于请求刷新所述目标域名下的资源的刷新请求；

所述处理模块52，还用于确定所述索引列表中是否存在所述目标域名；当所述索引列表中存在所述目标域名时，追溯所述预设时长内所述边缘节点接收到的刷新请求以得到第一集合；

所述刷新模块53，还用于刷新所述第一集合内各刷新请求中每个刷新请求所请求刷新的资源。

一种可行的实现方式中，所述处理模块52，还用于当无法确定出所述索引列表中是否存在所述目标域名时，确定所述边缘节点已缓存的资源中是否存在所述目标域名下的资源；

所述刷新模块53，还用于当所述边缘节点已缓存的资源中存在所述目标域名下的资源时，刷新所述目标域名下的资源。

一种可行的实现方式中，所述收发模块51，还用于接收来自终端设备的业务请求；

所述处理模块52，还用于当已缓存的资源中没有所述业务请求所请求的资源时，从源站获取所述业务请求所请求的资源并缓存；根据所述业务请求所请求的资源的域名更新所述索引列表。

一种可行的实现方式中，所述处理模块52，在所述接收模块接收来自调度中心的之前，还用于当所述缓存节点已缓存的资源中存在对应多个域名的资源时，将所述多个域名中的每个域名存储在所述索引列表中。

一种可行的实现方式中，所述处理模块52，用于当所述刷新请求与之前接收到的刷新请求不属于同一个批次时，确定所述索引列表中是否存在所述刷新请求携带的目标域名，以得到判断结果；当所述判断结果指示所述索引列表中存在所述目标域名时，确定第二集合中所有的刷新请求都用于刷新所述目标域名下的资源，所述第二集合中的刷新请求是所述边缘节点接收到的一个批次的刷新请求，所述第二集合中的不同刷新请求所请求刷新的资源不同；当所述判断结果指示所述索引列表中不存在所述目标域名时，确定所述第二集合中所有的刷新请求都不是用于刷新所述目标域名下的资源。

一种可行的实现方式中，所述处理模块52，还用于将所述索引列表存储在所述边缘节点的非易失性存储器中并定期更新。

一种可行的实现方式中，所述处理模块52，还用于在所述收发模块51接收来自调度中心的刷新请求之前，当所述边缘节点重启或所述边缘节点提供的服务重启时，从所述非易失性存储器读取所述索引列表并加载至内存。

一种可行的实现方式中，所述处理模块52，还用于在所述收发模块51接收来自调度中心的刷新请求之前，当所述索引列表未成功存储在所述非易失性存储器时，根据配置文件生成所述索引列表，所述配置文件指示配置给所述边缘节点的域名；将所述索引列表加载至内存。

本申请实施例提供的资源刷新装置，可以执行上述实施例中边缘节点的动作，其实现原理和技术效果类似，在此不再赘述。

图6为本申请实施例提供的一种资源刷新装置的示意图。该资源刷新装置600集成在调度中心上，该资源刷新装置包括：收发模块61和处理模块62。

处理模块62，用于按批次生成刷新请求以得到第二集合，所述第二集合中的各刷新请求用于请求刷新目标域名下的不同资源；

收发模块61，用于向网络中的各边缘节点发送所述第二集合中的各刷新请求。

本申请实施例提供的资源刷新装置，可以执行上述实施例中调度中心的动作，其实现原理和技术效果类似，在此不再赘述。

图7为本申请实施例提供的一种电子设备的结构示意图。如图7所示，该电子设备700例如为上述的边缘节点或调度中心，该电子设备700包括：

处理器71和存储器72；

所述存储器72存储计算机指令；

所述处理器71执行所述存储器72存储的计算机指令，使得所述处理器71执行如上边缘节点实施的资源刷新方法；或者，使得所述处理器71执行如上调度中心实施的资源刷新方法。

处理器71的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，该电子设备700还包括通信部件73。其中，处理器71、存储器72以及通信部件73可以通过总线74连接。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上边缘节点或调度中心实施的资源刷新方法。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包含计算机程序，计算机程序被处理器执行时实现如上边缘节点或调度中心实施的资源刷新方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (12)

1.一种资源刷新方法，其特征在于，应用于边缘节点，所述方法包括：

接收来自调度中心的刷新请求，所述刷新请求用于请求刷新目标域名下的资源；

确定索引列表中是否存在所述目标域名，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名；

当所述索引列表中存在所述目标域名时，刷新所述目标域名下的资源；

当无法确定出所述索引列表中是否存在所述目标域名时，确定所述边缘节点已缓存的资源中是否存在所述目标域名下的资源；

当所述边缘节点已缓存的资源中存在所述目标域名下的资源时，刷新所述目标域名下的资源。

2.根据权利要求1所述的方法，其特征在于，还包括：

当所述索引列表中不存在所述目标域名时，后续预设时长内，每次接收到用于请求刷新所述目标域名下的资源的刷新请求后，向所述调度中心发送刷新完成响应。

3.根据权利要求2所述的方法，其特征在于，还包括：

所述预设时长后，再次接收用于请求刷新所述目标域名下的资源的刷新请求；

确定所述索引列表中是否存在所述目标域名；

当所述索引列表中存在所述目标域名时，追溯所述预设时长内所述边缘节点接收到的刷新请求以得到第一集合；

刷新所述第一集合内各刷新请求中每个刷新请求所请求刷新的资源。

4.根据权利要求1-3任一项所述的方法，其特征在于，还包括：

接收来自终端设备的业务请求；

当已缓存的资源中没有所述业务请求所请求的资源时，从源站获取所述业务请求所请求的资源并缓存；

根据所述业务请求所请求的资源的域名更新所述索引列表。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述接收来自调度中心的之前，还包括：

当所述缓存节点已缓存的资源中存在对应多个域名的资源时，将所述多个域名中的每个域名存储在所述索引列表中。

6.根据权利要求1-3任一项所述的方法，其特征在于，所述确定索引列表中是否存在所述目标域名，包括：

当所述刷新请求与之前接收到的刷新请求不属于同一个批次时，确定所述索引列表中是否存在所述刷新请求携带的目标域名，以得到判断结果；

当所述判断结果指示所述索引列表中存在所述目标域名时，确定第二集合中所有的刷新请求都用于刷新所述目标域名下的资源，所述第二集合中的刷新请求是所述边缘节点接收到的一个批次的刷新请求，所述第二集合中的不同刷新请求所请求刷新的资源不同；

当所述判断结果指示所述索引列表中不存在所述目标域名时，确定所述第二集合中所有的刷新请求都不是用于刷新所述目标域名下的资源。

7.根据权利要求1-3任一项所述的方法，其特征在于，还包括：

将所述索引列表存储在所述边缘节点的非易失性存储器中并定期更新。

8.根据权利要求7所述的方法，其特征在于，所述接收来自调度中心的刷新请求之前，还包括：

当所述边缘节点重启或所述边缘节点提供的服务重启时，从所述非易失性存储器读取所述索引列表并加载至内存。

9.根据权利要求7所述的方法，其特征在于，所述接收来自调度中心的刷新请求之前，还包括：

当所述索引列表未成功存储在所述非易失性存储器时，根据配置文件生成所述索引列表，所述配置文件指示配置给所述边缘节点的域名；

将所述索引列表加载至内存。

10.一种资源刷新装置，其特征在于，集成在边缘节点，所述装置包括：

收发模块，用于接收来自调度中心的刷新请求，所述刷新请求用于请求刷新目标域名下的资源；

处理模块，用于确定索引列表中是否存在所述目标域名，所述索引列表中存储所述边缘节点已缓存的资源中每个资源的域名；

刷新模块，用于当所述索引列表中存在所述目标域名时，刷新所述目标域名下的资源；所述刷新模块还用于当无法确定出所述索引列表中是否存在所述目标域名时，确定所述边缘节点已缓存的资源中是否存在所述目标域名下的资源；所述刷新模块还用于当所述边缘节点已缓存的资源中存在所述目标域名下的资源时，刷新所述目标域名下的资源。

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

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至9任一所述的方法。