依赖文件缓存更新的方法、装置、计算机设备及存储介质与流程

1.本发明涉及编译构建技术领域，更为具体地，本发明能够提供一种依赖文件缓存更新的方法、装置、计算机设备及存储介质。


背景技术：

2.随着云原生(cloudnative)的兴起，越来越多应用逐渐往云上迁移，使得应用微服务化。编译构建是一种实现应用微服务化的有效手段，具有构建效率高、构建速度快及成本低等优点，可用于云端大规模集群构建。在进行大规模集群并发构建时，只要构建节点本地没有所需要的依赖文件缓存，一般都会从外部依赖库去拉取依赖文件。这种方式虽然能够实现为当前节点提供对应的依赖文件，但是依赖文件的下载时长成为了编译构建效率的瓶颈，该问题在超大规模集群情况下更为明显；从外部依赖库下载所需依赖的时间越长，则导致编译构建耗时越长，编译构建效率越低。


技术实现要素：

3.为解决常规的编译构建方案存在耗时长和效率低的问题，本发明具体能够提供一种依赖文件缓存更新的方法、装置、计算机设备及存储介质，以达到提高编译构建效率和减少编译构建耗时等一个或多个技术目的。
4.为实现上述的技术目的，本发明具体能够提供一种依赖文件缓存更新的方法，应用于待构建集群的第一节点，该依赖文件缓存更新的方法包括但不限于如下至少一个步骤。
5.基于从第一节点本地依赖缓存中读取的第一依赖文件，生成第一依赖文件的第一缓存信息；所述第一缓存信息用于记录第一节点本地依赖缓存信息。
6.以所述第一缓存信息为依据，查询编译构建命令所需的第二依赖文件在第一节点的命中结果。
7.根据所述命中结果为未命中，查询至少一个第二节点的所述第二依赖文件的缓存结果。
8.根据所述缓存结果为存在，从具有第二依赖文件的第二节点获取所述第二依赖文件。
9.基于所述第二依赖文件刷新第一缓存信息，以得到第二缓存信息；所述第二缓存信息用于记录刷新后的第一节点本地依赖缓存信息。
10.本发明的一种可实施方式中，所述根据所述缓存结果为存在，从具有第二依赖文件的第二节点获取所述第二依赖文件，包括：如果多个第二节点缓存有所述第二依赖文件，分别获取所述多个第二节点的节点下载连接数；对获取的所有节点当前正在并发下载的下载连接数进行排序，以得到排序结果；根据所述排序结果从具有最小节点下载连接数的第二节点下载所述第二依赖文件。
11.本发明的一种可实施方式中，所述从具有第二依赖文件的第二节点获取所述第二
依赖文件之后包括：根据第二依赖文件大小和第一依赖文件大小，确定本地依赖缓存是否达到配置的缓存上限；如果达到所述缓存上限，删除至少一个第一依赖文件，并在本地依赖缓存中存储所述第二依赖文件；如果未达到所述缓存上限，在本地依赖缓存中存储所述第二依赖文件。
12.本发明的一种可实施方式中，所述删除至少一个第一依赖文件包括：读取所述第一缓存信息或所述第二缓存信息中第一依赖文件的访问时间；至少删除访问时间最早的第一依赖文件。
13.本发明的一种可实施方式中，所述生成第一依赖文件的第一缓存信息包括：获取各个所述第一依赖文件的访问时间、文件名、本地存储路径以及大小；基于所述访问时间确定第一依赖文件的缓存数据结构；按照所述缓存数据结构，对所述第一依赖文件的访问时间、文件名、本地存储路径以及大小进行存储，以生成第一依赖文件的第一缓存信息。
14.本发明的一种可实施方式中，根据所述缓存结果为不存在或者从第二节点获取所述第二依赖文件失败，从具有第二依赖文件的外部依赖库获取所述第二依赖文件。
15.为实现上述的技术目的，本发明还能够提供一种依赖文件缓存更新的装置，应用于待构建集群的第一节点，该依赖文件缓存更新的装置包括但不限于缓存信息生成单元、命中结果查询单元、缓存结果查询单元、依赖文件获取单元以及缓存信息刷新单元。
16.缓存信息生成单元，用于基于从第一节点本地依赖缓存中读取的第一依赖文件，生成第一依赖文件的第一缓存信息；所述第一缓存信息用于记录第一节点本地依赖缓存信息。
17.命中结果查询单元，用于以所述第一缓存信息为依据，查询编译构建命令所需的第二依赖文件在第一节点的命中结果。
18.缓存结果查询单元，用于根据所述命中结果为未命中，查询至少一个第二节点的所述第二依赖文件的缓存结果。
19.依赖文件获取单元，用于根据所述缓存结果为存在，从具有第二依赖文件的第二节点获取所述第二依赖文件。
20.缓存信息刷新单元，用于基于所述第二依赖文件刷新第一缓存信息，以得到第二缓存信息；所述第二缓存信息用于记录刷新后的第一节点本地依赖缓存信息。
21.本发明的一种可实施方式中，所述依赖文件获取单元，用于根据多个第二节点缓存有所述第二依赖文件，分别获取所述多个第二节点的节点下载连接数；所述依赖文件获取单元用于对获取的所有节点当前正在并发下载的下载连接数进行排序，以得到排序结果；所述依赖文件获取单元用于根据所述排序结果从具有最小节点下载连接数的第二节点下载所述第二依赖文件。
22.为实现上述的技术目的，本发明还能够提供一种计算机设备，计算机设备包括存储器和处理器，所述存储器中可存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器可执行本发明任一实施例所述依赖文件缓存更新的方法的步骤。
23.为实现上述的技术目的，本发明还可具体提供一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得所述一个或多个处理器执行本发明任一实施例所述依赖文件缓存更新的方法的步骤。
24.本发明的有益效果为：
25.本发明根据生成的第一缓存信息判断当前节点(即本地节点)是否有所需依赖文件，并在当前节点没有所需依赖文件时可从当前节点外的其他节点获取该依赖文件，以将第一缓存信息刷新为用于下一次缓存命中结果查询的第二缓存信息。可见本发明在构建节点本地没有所需要的依赖文件时能够从其他相连接的节点快速获取所需依赖文件，极大缩短了所需依赖的下载耗时，以达到减少编译构建耗时和提高编译构建效率等技术目的。
附图说明
26.图1示出了本发明一个或多个实施例中依赖文件缓存更新的方法的流程示意图。
27.图2示出了本发明一个或多个实施例中编译构建依赖缓存算法详细流程示意图。
28.图3示出了本发明一个或多个实施例中本地存储的依赖文件的目录层次示意图。
29.图4示出了本发明一个或多个实施例中图3中的依赖文件缓存数据结构示意图。
30.图5示出了本发明一个或多个实施例中通过依赖文件(file6)更新缓存的可选流程示意图。
31.图6示出了本发明一个或多个实施例中淘汰依赖文件(file5)以及存放依赖文件(file6)的示意图。
32.图7示出了本发明一个或多个实施例中图6中的依赖文件缓存数据结构示意图。
33.图8示出了本发明一个或多个实施例中依赖文件缓存更新的装置的组成示意图。
34.图9示出了本发明一个或多个实施例中计算机设备内部结构的组成示意图。
具体实施方式
35.下面结合说明书附图对本发明提供的一种依赖文件缓存更新的方法、装置、计算机设备及存储介质进行详细的解释和说明。
36.面对直接从外部依赖库下载依赖的方式存在依赖文件下载用时过长，以及导致的编译构建耗时长和编译构建效率低等问题，本发明提供了一种全新的构建集群依赖缓存技术方案，以明显地缩短依赖文件的下载耗时，极大减少编译构建耗时，突破编译构建效率瓶颈，从而解决常规编译构建技术存在的一个或多个问题，本发明采用的技术方案细节具体说明如下。
37.如图1所示，并可结合图2，本发明一个或多个实施例具体能够提供一种依赖文件缓存更新的方法，可应用于待构建集群的第一节点，该依赖文件缓存更新的方法包括但不限于如下的至少一个步骤，具体说明如下。
38.步骤100，基于从第一节点本地依赖缓存中读取的第一依赖文件，生成第一依赖文件的第一缓存信息；第一缓存信息用于记录第一节点本地依赖缓存信息。可理解的是，本发明第一节点本地依赖缓存中往往有多个第一依赖文件，这些依赖文件可事先从外部依赖库下载。
39.如图3所示，并可结合图4，本发明事先能够从外部依赖库下载的各第一依赖文件存储到本地依赖缓存中。本实施例图3中示出了依赖文件file1、依赖文件file2、依赖文件file3、依赖文件file4以及依赖文件file5：依赖文件file1和依赖文件file2均存储于目录路径p1下的目录路径p2中，即图示p1/p2路径中；依赖文件file3和依赖文件file4均存储于
目录路径p1下的目录路径p3下的目录路径p4中，即图示p1/p3/p4路径中，依赖文件file5存储于p1路径中。
40.本发明一个或多个实施例中生成第一依赖文件的第一缓存信息具体包括：获取各个第一依赖文件的访问时间、文件名、本地存储路径以及大小等缓存相关信息，并基于访问时间确定第一依赖文件的缓存数据结构，按照缓存数据结构，对第一依赖文件的访问时间、文件名、本地存储路径以及大小进行存储，以生成第一依赖文件的第一缓存信息。结合图3所示，本发明实施例涉及的依赖文件file1、依赖文件file2、依赖文件file3、依赖文件file4以及依赖文件file5存储于目标路径p1、目标路径p2以及目标路径p3、目标路径p4形成的存储层次架构中，依赖文件file1的访问时间为t1、依赖文件大小为s1、存储路径为p1/p2，依赖文件file2的访问时间为t2、依赖文件大小为s2、存储路径为p1/p2，依赖文件file3的访问时间为t3、依赖文件大小为s3、存储路径为p1/p3/p4，依赖文件file4的访问时间为t4、依赖文件大小为s4、存储路径为p1/p3/p4，依赖文件file5的访问时间为t5、依赖文件大小为s5、存储路径为p5，本发明实施例示出的依赖文件file1～file5按照图示的文件系统层级结构存储于本地硬盘上。
41.如图4所示，本发明一个或多个实施例中的缓存数据结构具体为哈希(hash)与双向链表数据结构，双向链表按依赖文件访问时间进行排序，如图示中的file2
→
file1
→
file3
→
file4
→
file5。其中，file2作为头依赖文件(head)，即访问时间最新的依赖文件；而file5作为尾依赖文件，即访问时间最早的依赖文件；本实施例基于双向链表数据结构可快速查找到访问时间最早的依赖文件，并基于哈希与双向链表数据结构能够快速查询依赖文件是否在本地缓存中。本发明实施例中第一缓存信息具体包括但不限于文件名、访问时间、文件大小、存储路径、哈希关键码(key)、双向链表信息等，本发明涉及的访问时间具体为最后访问时间，图4中的哈希关键码key1对应依赖文件file1和依赖文件file3、哈希关键码key2对应依赖文件file2、哈希关键码key3对应依赖文件file4和依赖文件file5。本发明实施例的双向链表按照访问时间进行排序，包括但不限于file2～file1链表信息、file1～file3链表信息、file3～file4链表信息以及file4～file5链表信息。
42.可选地，本发明实施例可以在集群上各节点都部署有代理模块，代理模块在首次启动时从本地依赖缓存中读取依赖文件，并构建依赖文件缓存信息，即生成本发明由文件名、访问时间、文件大小以及存储路径等构成的第一缓存信息；对于本实施例的代理模块，图4中依赖文件file1-file5的文件最后访问时间顺序依次为：t2＞t1＞t3＞t4＞t5，则可直接确定最新访问的依赖文件具体为依赖文件file2。
43.步骤200，以第一缓存信息为依据，查询编译构建命令所需的第二依赖文件在第一节点的命中结果。应当理解的是，本发明实施例涉及的编译构建(cloudbuild)是一种全面管理的持续集成(ci，continuous integration)与持续交付(cd，continuous delivery)平台，并能够用来快速且大规模构建、测试以及部署软件，以及可实现编译构建云端化，可见本发明具体能够提供一种编译构建依赖缓存的方法。本发明实施例中的编译构建命令可为maven(麦文)构建命令，maven是apache(阿帕奇)开源社区推出的一款基于项目对象模型(pom，project object model)的，且通过描述信息来管理项目的构建、报告及文档的软件项目管理工具；本发明实施例可在maven构建程序中嵌入maven插件，并通过maven插件预先对本地依赖缓存进行预处理，实现向本地代理模块查询依赖文件缓存是否命中。当然，本发
明实施例具体使用的编译构建命令并不限于此。
44.步骤300，根据命中结果为未命中，查询至少一个第二节点的第二依赖文件的缓存结果。可理解的是，其中第二节点与第一节点不同。本发明实施例中根据命中结果为命中，则刷新第一缓存信息中的第一依赖文件的访问时间，进而使代理模块刷新缓存信息，然后通过上述maven插件继续处理下一个依赖文件，直至当前所需所有依赖文件均已处理完成。与常规的编译构建惯用的同步方案不同，本发明实施例中第一节点与第二节点之间、不同的第二节点之间各自缓存的依赖文件均不进行同步，第一节点与第二节点之间、不同的第二节点之间各自的缓存信息均不进行同步。其中，若本地节点未命中第二依赖文件，本发明实施例向集群中其他节点的代理模块(除了本地节点代理模块)查询第二依赖文件是否存在，并能够获取存在第二依赖文件的节点、下载路径、文件大小以及节点下载连接数等相关信息。
45.步骤400，根据缓存结果为存在，从具有第二依赖文件的第二节点获取第二依赖文件。根据缓存结果为不存在或者从第二节点获取第二依赖文件失败，则从具有第二依赖文件的外部依赖库获取第二依赖文件，若下载成功，则执行后续的依赖文件存储和缓存信息更新步骤；若第二依赖文件下载失败则结束(编译构建停止)。本发明实施例可通过maven插件获取所需依赖文件的下载地址，并向具有最小连接数的节点实现依赖文件成功下载，并通知该节点上的代理模块刷新文件缓存信息，包括但不限于刷新该节点所存储的依赖文件的访问时间；并能够通知当前节点(本地节点)代理模块插入缓存文件的信息。本发明实施例可在当前编译构建命令当前需要的所有依赖文件经过maven插件处理之后，则可以进行编译构建。
46.如图2所示，本发明实施例中根据缓存结果为存在，从具有第二依赖文件的第二节点获取第二依赖文件，上述过程具体可包括：如果多个第二节点缓存有第二依赖文件，分别获取多个第二节点的节点下载连接数；对获取的所有节点当前正在并发下载的下载连接数进行排序，以得到排序结果；根据排序结果从具有最小节点下载连接数的第二节点下载第二依赖文件。可选地，本发明实施例或能够在向第二节点查询第二依赖文件的缓存结果的同时，可获取下载连接数。在具体实施时，当前节点代理模块可用于对获取的所有节点当前正在并发下载的下载连接数进行排序，并能用于将节点下载连接数排序结果返回给maven插件，maven插件用于依次向具有最小连接数的节点进行依赖文件下载，直至所需依赖文件下载成功。本发明实施例通过可具有最小节点下载连接数的第二节点下载第二依赖文件，达到下载负荷均衡的目的，以避免某个第二节点承受数据下载负荷过大的问题，保证节点下载负荷均衡，进而有助于进一步缩短依赖文件的获取时长，进一步提高本发明编译构建效率。
47.可选地，本发明实施例从具有第二依赖文件的第二节点获取第二依赖文件之后还可包括：根据第二依赖文件大小和第一依赖文件大小，确定本地依赖缓存是否达到配置的缓存上限，即本发明实施例的第二依赖文件与所有第一依赖文件所需要存储量总和是否已达到缓存上限；如果达到缓存上限，删除至少一个第一依赖文件，以及在本地依赖缓存中存储第二依赖文件；如果未达到缓存上限，直接在本地依赖缓存中存储第二依赖文件；本实施例存储第二依赖文件的过程即在本地缓存中插入第二依赖文件的过程。本发明配置的缓存上限小于或等于本地节点缓存总量，该缓存上限具体值可根据实际情况具体设置，本实施
例对此不进行限定。相比于常规技术只能够手动维护和清理缓存的方式，本发明实现了根据新的依赖文件自动清理缓存中的历史依赖文件，以达到避免本地节点存储空间无人清理而一直增加的问题。
48.具体地，本实施例删除至少一个第一依赖文件可包括：读取第一缓存信息或第二缓存信息中第一依赖文件的访问时间，本发明涉及的访问时间具体为最后访问时间，以及至少删除访问时间最早的一个或多个第一依赖文件；本发明实施例删除最早访问时间的第一依赖文件的数量根据是否可存入第二依赖文件为准，如果淘汰一个访问时间最早的第一依赖文件后，则在存入第二依赖文件后的所有依赖文件占用的存储量小于配置的缓存上限，则淘汰一个第一依赖文件即可，否则需要淘汰多个第一依赖文件，直至满足如上的所有依赖文件占用的存储量要求，即保证剩余的第一依赖文件与第二依赖文件占用的总存储量小于配置的缓存上限。本发明实施例采用淘汰掉最近最少使用的至少一个依赖文件的方式，有助于在释放缓存空间的同时尽可能地为节点保留有用依赖文件，延长有用依赖文件的缓存时长，以便于节点在需要相应的有用依赖文件时可从本地直接取得，极大地缩短依赖文件获取时长，提升编译构建效率。本发明具体实施时采用的缓存清理机制可以结合lru(least recently used，最近最少使用)算法等实现，以使本发明上述改进后的方案更好地适用于maven编译构建等场景。
49.步骤500，基于第二依赖文件刷新第一缓存信息，以得到第二缓存信息；第二缓存信息用于记录刷新后的第一节点本地依赖缓存信息。本发明实施例刷新第一缓存信息包括但不限于向第一缓存信息中插入第二依赖文件的文件名、访问路径、文件大小及访问时间等缓存相关信息。对于需要淘汰至少一个第一依赖文件的情况，则本发明刷新第一缓存信息还包括删除被淘汰的第一依赖文件在第一缓存信息中的相关信息，以通过刷新第一缓存信息方式得到的第二缓存信息记录当前节点中更新后依赖文件相关信息，从而便于为后续编译构建需求提供更好的数据支撑，提升编译构建效率。
50.如图5所示，本发明示例性地在图3示出的本地依赖文件缓存基础上进行maven编译构建，例如maven插件需要下载依赖文件file6，该依赖文件在本地节点代理模块查询缓存时未命中，则向构建集群中的其他节点各代理模块查询是否存在依赖文件file6，如果有节点存在依赖文件file6，则从对应的其他节点下载，否则从外部依赖库下载。以从其他节点下载该依赖文件file6，为例，本发明从具有最小连接的节点下载依赖文件file6到本地依赖缓存，成功下载后通知其他节点刷新依赖文件的缓存信息，从而刷新依赖文件file6在原存储节点中的访问时间信息；以及通知本地节点代理模块插入依赖文件file6相关的信息，进而在缓存达到上限的情况下淘汰访问时间最早的一个或多个依赖文件，以使本实施例能够满足配置的缓存上限的基础上在本地节点存储所需的依赖文件file6。
51.如图6和图7所示，相比于图3和图4中的原有依赖文件存储情况，对于具有最早访问时间特征的依赖文件file5，本示例中需要淘汰访问时间最早的依赖文件file5，以满足在存储依赖文件file6后的本地总存储量需要低于缓存上限的要求。图6中示出了依赖文件file6的访问时间为t6、文件大小为s6以及存储路径为p1/p2，删除依赖文件file6之后，可将本示例中的依赖文件file6存储于依赖文件file1、file2所在的目录路径下。图7中示出更新后的依赖文件缓存数据结构，可知本示例中关键码key1～key3、依赖文件file1～file4本身未发生改变，但依赖文件file6替换了依赖文件file5原有的逻辑位置：(1)关键
码key3指向依赖文件file4和依赖文件file6；(2)链表信息变化，头依赖文件变为依赖文件file6，则新的头依赖文件file6建立与原来的头依赖文件file2的链表信息，依赖文件file2与依赖文件file1、依赖文件file1与依赖文件file3、依赖文件file3与依赖文件file4之间的链表信息不发生变化，由于原尾依赖文件file5的删除，依赖文件file4失去了与原尾依赖文件file5的链表关联，而且与原尾依赖文件file5具有链表关联的依赖文件file4成为新的尾依赖文件。
52.本发明在本地节点无所需依赖文件时，能够从与本地节点通信的其他节点中下载所需依赖文件，该方式不仅极大缩短了所需依赖的下载耗时，以降低本地节点编译构建耗时和效率，而且在大规模构建集群并发构建从外部依赖库下载依赖时，极大地减少了外部依赖库拉取压力，显著提高了大规模构建集群整体的编译构建效率。本发明提供了一种全新的缓存清理机制，当本地缓存空间达到一定阈值后通过新的依赖文件缓存触发缓存的清理，并可淘汰掉最近最少使用的依赖文件，实现清理缓存的同时，增加有用依赖文件的缓存时长。
53.如图8所示，与依赖文件缓存更新的方法基于同一发明技术构思，本发明一个或多个实施例还能够提供一种依赖文件缓存更新的装置，可应用于待构建集群的第一节点。
54.该依赖文件缓存更新的装置可以包括但不限于缓存信息生成单元、命中结果查询单元、缓存结果查询单元、依赖文件获取单元以及缓存信息刷新单元，各单元具体说明如下。
55.缓存信息生成单元，用于基于从第一节点本地依赖缓存中读取的第一依赖文件，生成第一依赖文件的第一缓存信息；第一缓存信息用于记录第一节点本地依赖缓存信息。
56.具体地，缓存信息生成单元用于获取各个第一依赖文件的访问时间、文件名、本地存储路径以及大小，并用于基于访问时间确定第一依赖文件的缓存数据结构。
57.本实施例缓存信息生成单元用于按照缓存数据结构，对第一依赖文件的访问时间、文件名、本地存储路径以及大小进行存储，以生成第一依赖文件的第一缓存信息。
58.命中结果查询单元，用于以第一缓存信息为依据，查询编译构建命令所需的第二依赖文件在第一节点的命中结果。
59.缓存结果查询单元，用于根据命中结果为未命中，查询至少一个第二节点的第二依赖文件的缓存结果。其中，第二节点与第一节点不同。
60.依赖文件获取单元，用于根据缓存结果为存在，从具有第二依赖文件的第二节点获取第二依赖文件。
61.可选地，依赖文件获取单元可用于根据多个第二节点缓存有第二依赖文件，分别获取多个第二节点的节点下载连接数；依赖文件获取单元用于对获取的所有节点当前正在并发下载的下载连接数进行排序，以得到排序结果；依赖文件获取单元能够用于根据排序结果从具有最小节点下载连接数的第二节点下载第二依赖文件。
62.可选地，依赖文件获取单元还能够用于根据缓存结果为不存在或者从第二节点获取第二依赖文件失败，从具有第二依赖文件的外部依赖库获取第二依赖文件。
63.可选地，本发明一个或多个实施例中的依赖文件缓存更新的装置还可包括依赖文件存储模块。依赖文件存储模块用于根据第二依赖文件大小和第一依赖文件大小，确定本地依赖缓存是否达到配置的缓存上限；该依赖文件存储模块可用于根据达到缓存上限，删
除至少一个第一依赖文件，并在本地依赖缓存中存储第二依赖文件；或者，该依赖文件存储模块可用于根据未达到缓存上限，在本地依赖缓存中存储第二依赖文件。
64.可选地，依赖文件存储模块可用于读取第一缓存信息或第二缓存信息中第一依赖文件的访问时间，依赖文件存储模块可用于至少删除访问时间最早的第一依赖文件。
65.缓存信息刷新单元，用于基于第二依赖文件刷新第一缓存信息，以得到第二缓存信息；第二缓存信息用于记录刷新后的第一节点本地依赖缓存信息。
66.可选地，缓存信息刷新单元用于根据命中结果为命中，刷新第一缓存信息中的第一依赖文件的访问时间。
67.如图9所示，与依赖文件缓存更新的方法基于同一发明技术构思，本发明一个或多个实施例还能够提供一种计算机设备，计算机设备可包括但不限于存储器和处理器，存储器中存储有计算机可读指令，该计算机可读指令被处理器执行时，使得处理器执行本发明任一实施例中依赖文件缓存更新的方法的步骤。其中，本发明涉及的依赖文件缓存更新的方法的详细执行过程已在本说明书中有详细的记载，此处不再进行赘述。
68.如图9所示，与依赖文件缓存更新的方法基于同一发明技术构思，本发明一个或多个实施例还可提供一种存储有计算机可读指令的存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行本发明任一实施例中依赖文件缓存更新的方法的步骤。其中，本发明具体涉及的依赖文件缓存更新的方法的详细执行过程已在本说明书中有详细的记载，此处不再进行赘述。
69.在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读存储介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读存储介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读存储介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram，random access memory)，只读存储器(rom，read-only memory)，可擦除可编辑只读存储器(eprom，erasable programmable read-only memory，或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom，compact disc read-only memory)。另外，计算机可读存储介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。
70.应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga，programmable gate array)，现场可编程门阵列(fpga，field programmable gate array)等。
71.在本说明书的描述中，参考术语“本实施例”、“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
72.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
73.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明实质内容上所作的任何修改、等同替换和简单改进等，均应包含在本发明的保护范围之内。