背景技术

  内容分发网络（CDN），其核心原理是通过其各个层级的节点，将远端源站的内容资源缓存至更靠近用户的节点上，当用户尝试访问的资源在本地缓存中未命中时，缓存服务器将回源拉取资源，并据此进行响应。CDN旨在减轻源站的负载，同时提升用户的访问速度。

  当检测到用户访问的资源在本地缓存中未命中时，CDN服务提供商通常会采取以下两种策略进行回源处理：

  1）完整回源：完整回源是CDN回源的一种基本策略，当本地缓存中不存在时，缓存服务器会完整地将请求转发到源站，源站会返回完整的文件或资源。缓存服务器在接收到这些文件或资源后，会将其缓存到本地，以便将来能够直接服务其它用户请求。
完整回源策略的优点是简单直接，但面对包含Range请求头的大文件（如视频文件、游戏或软件安装包等）时，其效率会大打折扣。比如，当Range请求范围指向文件后部时，用户将面临长时间的等待，这对视频流等应用而言尤为不利，另外，当Range请求范围较小时，完整回源的方式会放大回源，导致成本浪费。

  2）分片回源：分片回源是一种更为复杂的回源策略，在分片回源中，会将用户请求的文件分割成多个较小的分片（或称为“片段”），然后以Range的形式向源站请求这些分片，源站会返回这些分片，缓存服务器在接收到分片后会将它们缓存到本地，并按照正确的顺序将这些分片组合成完整的文件。
分片回源在处理“大文件+Range”请求时，是按需回源，只回源用户请求范围内的分片，可以大大减少用户等待时长，节约回源带宽，在实际应用中也较为广泛。然而，这种策略也面临一些挑战，比如，面对复杂的源站环境和多变的客户需求，也暴露出一个棘手问题——源站兼容性问题。由于源站服务器对HTTP规范的支持程度参差不齐，部分服务器仅支持完整回源请求，不支持分片回源的Range请求。在这种情况下，开启分片功能可能导致回源请求被错误处理，进而影响用户体验。比如，当启用分片功能后，用户请求的是一个完整文件，分片回源时会对客户端的请求进行特殊处理，将其转化为多个Range请求以进行分片传输，如果源站服务器不支持这种Range请求的分片机制，那么分片功能将无法正确执行。这种不兼容的情况会导致CDN无法向用户返回正确的响应，原本用户能够直接获取到的完整文件，在通过CDN加速后反而会出现错误响应。这会严重影响用户体验，降低用户满意度，还可能导致客户投诉，对服务提供商的声誉造成负面影响。

  由上可以看出，CDN服务提供商在处理用户请求的资源未命中时，两种主要的回源策略：完整回源和分片回源。完整回源策略虽然简单直接，但在处理大文件或带有Range请求头的文件时效率较低，可能导致用户等待时间过长，特别是在视频流等应用中表现尤为明显，此外，当Range请求范围较小时，完整回源可能会浪费回源带宽，增加成本。相比之下，分片回源策略在处理大文件和带有Range请求头的文件时更为高效。它通过按需回源，只回源用户请求范围内的分片，可以大大减少用户等待时长，并节约回源带宽。然而，由于源站服务器对HTTP规范的支持程度不同，部分服务器可能不支持分片回源的Range请求，分片回源策略也面临源站兼容性问题，可能导致分片回源请求被错误处理，影响用户体验。

  因此，CDN服务提供商在选择回源策略时需要根据用户的具体需求、当前缓存状态和源站的特性进行综合考虑，但是，如图1(原有方案和本发明的对比图)所示，原有方案在使用以上两种回源方式时，传统做法是事先配置好回源方式，接收请求后，根据预设的回源方式查询对应的缓存索引(完整缓存或者分片缓存)，若请求的资源在缓存中不存在，则进行回源获取。这样的做法存在明显的局限性：

  1）两种回源方式之间是非此即彼的，对应的缓存也是彼此独立的，一旦在两种回源方式之间进行切换，就必须重新回源获取，这不仅增加运营成本，还会影响服务质量和客户体验。

  2）完整回源或分片回源都有其特定的适用场景，事先很难预测所有的情况，这种刚性预设的回源方式使得CDN系统在应对多变的客户需求和源站响应时显得力不从心。

实现方案

  现提出一种基于双查询缓存索引的自适应回源方法，结合图1(原有方案和本发明的对比图)，本发明的具体步骤介绍如下：

  1）在接收到客户端的请求后，不再按照原有预设配置的方法来决定回源方式和查询哪种缓存索引，而是采用双查询缓存索引的方法，即首先查询完整缓存的索引，随后再查询分片缓存的索引。

  2）在查询时，首先检索完整缓存的索引。若检索结果显示存在完整的缓存索引，将直接使用该完整缓存进行响应，从而避免进一步查询分片缓存的索引。这一策略基于完整缓存已经能够满足快速且稳定的响应需求，同时，即使分片缓存的索引存在，也可能因分片缺失而导致数据不完整。因此，当完整缓存可用时，优先采用完整缓存。

  3）若完整缓存的索引不存在，再对分片缓存的索引进行查询，若查询结果显示分片缓存的索引存在，这表明之前已经成功执行过分片回源操作，并且源站支持Range请求，在这种情况下，我们将使用已有的分片缓存来完成响应，如果在处理过程中发现有分片缺失，则触发分片回源。

  4）若完整缓存的索引和分片缓存的索引均不存在，本方法将进一步解析客户端请求，查看其是否携带Range请求头：

  a.如果请求中携带有Range请求头，这表明客户端需要特定范围的数据，在这种情况下，优先使用分片回源策略，这样可以在不改变客户端请求性质的前提下，根据请求的具体范围进行分片回源，这不仅确保了我们能够迅速响应客户端的需求，提升了用户体验，还避免了不必要的回源带宽消耗；

  b.如果客户端请求未携带Range请求头，这表明客户端请求的是整个文件，在这种情况下，优先使用完整回源策略，这样不仅不会影响用户体验，还能确保数据的完整性和流畅性，同时，避免了因分片回源可能带来的额外网络交互和潜在的延迟，也降低了业务逻辑的复杂度。更重要的是，对于客户端完整请求的场景，分片回源并不提供额外收益，因此，这种情况下，完整回源是一种更为高效且经济的解决方案；

  本发明的主要思路是，采用了一种自适应的回源策略，结合双查询缓存索引的方法，首先查询完整缓存索引，若存在则直接使用；若不存在，则查询分片缓存索引。若分片缓存索引存在，将使用分片缓存响应，否则进一步分析客户端请求。对于携带Range请求头的客户端请求，优先采用分片回源策略，确保快速响应和减少带宽消耗；对于未携带Range请求头的全文件请求，则优先采用完整回源策略，确保数据完整性和降低业务逻辑复杂度。这一方案通过双查询缓存索引方法和自适应的回源策略，灵活适应不同场景，确保快速响应、减少带宽消耗、保障数据完整性和降低业务逻辑复杂度，从而有效提升了用户体验和资源利用效率。

实施例作详细说明

  1）接收客户端请求，不再仅仅一句是否包含“Ctl-Store: split”请求头来区分完整回源还是分片回源，而是先查询完整缓存的索引，再查询分片缓存的索引。

  2）若查询结果显示完整缓存存在，则优先使用完整缓存完成客户端响应。

  3）若查询结果为完整缓存不存在但分片缓存存在，这说明第一次客户端请求时使用的是分片回源，并且源站满足分片回源的条件，如果在处理过程中发现有缺失分片，可以正常触发新的分片回源请求。

  4）若查询结果显示完整缓存和分片缓存均不存在，则进一步解析客户端请求头，根据是否包含Range请求头来判断请求类型。

  5）若请求头中包含Range请求头，表明客户端请求的是特定范围的数据，这种情况下，优先使用分片回源，分片回源请求只是将客户端的一个Range请求，转发为多个一定大小的分片回源请求，不会改变客户端请求性质，还可以做到及时响应客户端请求范围的数据。

 6）若请求头中未含Range请求头，说明客户端请求的是从头到尾的整个文件，在这种情况下，优先使用完整回源。完整回源策略不仅简单，而且不会影响用户体验，还可以避免因分片回源可能带来的额外网络交互和潜在的延迟，降低了业务逻辑的复杂度。