一种回源处理方法及装置与流程

本发明涉及计算机技术领域，尤其涉及一种回源处理方法及装置。

背景技术：

内容分发网络cdn是边缘缓存系统，是一种http反向代理和缓存的系统，这种系统通过.超文本传输协议http的统一资源定位符url生成一个cachekey，通过cachekey查询请求的对象是否在缓存中命中。如果命中则直接返回，如果不命中缓存那么要将请求反向代理到源站，术语称之为回源。对回源返回的对象，要返回给客户端，同时也将该对象写入缓存中。缓存中的对象遵循lru算法，最早写入缓存的对象最先被从缓存中删除。

源站failover解决的是由于源站压力过大产生的大量请求错误问题。现有技术是用健康检查的方式检查源站是否可用，通过给源站发送健康检查请求，如果请求不能响应，就将源站记录为宕机，请求不再回源到记录为宕机的机器，这样就减少了请求的错误比率。

现有技术中用健康检查的方式检查源站是否可用，但由于一般源站比较少，这种方法在源站压力大的情况不适用，因为如果一个源站被健康检查记录为宕机，那么压力就会全部集中到另一个源站上，这反而会增大该源站的压力，让错误率大为增加。

使用健康检查的方式，也难以应对源站随机产生的错误请求，这种错误请求可能是不连续的，这就无法触发健康检查的记录宕机功能，导致错误率降不下来。

技术实现要素：

为实现上述目的，本发明实施例提供一种回源处理方法及装置，通过设置可切换的不止一个回源ip，对每一个随机的回源错误都会实时进行故障切换，有效的降低了错误率。

一方面，本发明实施例提供一种回源处理方法，所述方法包括：

获取用户的查询请求，判断所述查询请求的对象是否存在缓存；

如果不存在缓存，则获取设定个数的回源ip；

取所述设定个数的回源ip中的一个回源ip进行对象返回；

若所述返回的对象出现错误，则根据预先设定条件再次通过该回源ip进行对象返回或者取所述设定个数的回源ip中的下一个回源ip进行对象返回；

重复上一步骤，直到所述返回的对象正确、或者前端服务器连接超时、或者所述预先设定条件中的故障切换次数耗尽，结束此次查询请求。

另一方面，本发明实施例还提供一种回源处理装置，所述装置包括：

缓存判断单元，用于获取用户的查询请求，判断所述查询请求的对象是否存在缓存；

回源ip确定单元，用于在不存在缓存的情况下，获取设定个数的回源ip；

对象返回单元，用于取所述设定个数的回源ip中的一个回源ip进行对象返回；

切换单元，用于在所述返回的对象出现错误时，根据预先设定条件再次通过该回源ip进行对象返回或者取所述设定个数的回源ip中的下一个回源ip进行对象返回；

控制单元，用于重复上一步骤，直到所述返回的对象正确、或者前端服务器连接超时、或者所述预先设定条件中的故障切换次数耗尽，结束此次查询请求。

上述技术方案具有如下有益效果：本发明与现有技术比较，不使用健康检查方式来记录宕机与否，这样首先不会在判断宕机的时候将请求完全打在另一个源站上，通常第二个源站之后的源站承受压力的能力不足，请求都打在第二个源站上容易导致源站宕机。健康检查的方式中，健康检查请求的间隔较难调整，间隔较大灵敏度不够，会在产生了较多的错误之后；才会切换，间隔较小又会让健康检查的请求本身消耗大量系统资源。而本申请技术方案通过设置可切换的不止一个回源ip，对每一个随机的回源错误都会实时进行故障切换，有效的降低了错误率。

附图说明

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

图1是本发明实施例的回源处理方法的流程图；

图2是本发明实施例的回源方法的流程图；

图3是本发明实施例的回源处理装置的结构示意图。

具体实施方式

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

如图1、2所示，为本发明实施例的回源处理方法的流程图，所述方法包括：

s101：获取用户的查询请求，判断所述查询请求的对象是否存在缓存。

优选地，在获取用户的查询请求后，通过四层代理服务或者七层代理服务将所述查询请求代理到缓存服务，通过所述缓存服务判断查询请求的对象是否存在缓存。其中，所述缓存服务、四层代理服务以及七层代理服务均通过缓存服务器实现运行。

s102：如果不存在缓存，则获取设定个数的回源ip。

优选地，通过后端源站的dns服务产生所述设定个数的回源ip。

s103：取所述设定个数的回源ip中的一个回源ip进行对象返回。

s104：若所述返回的对象出现错误，则根据预先设定条件再次通过该回源ip进行对象返回或者取所述设定个数的回源ip中的下一个回源ip进行对象返回。

优选地，所述预先设定条件通过与http相关的代理和缓存服务设置，所述预先设定条件包括每一个回源ip进行对象返回的重复次数以及总的故障切换次数。

s105：重复上一步骤，直到所述返回的对象正确、或者前端服务器连接超时、或者所述预先设定条件中的故障切换次数耗尽，结束此次查询请求。

优选地，与http相关的代理和缓存服务通过故障切换failover系统控制同一回源ip重复进行对象返回、以及切换不同回源ip进行对象返回。

具体地，回源故障切换failover系统是在与http相关的代理和缓存服务apachetrafficserver的基础上实现的，对每个源站的访问有重试机制，也有failover即故障切换的总次数。按照trafficserver的配置，为：configproxy.config.http.connect_attempts_max_retriesint5和configproxy.config.http.connect_attempts_rr_retriesint2，分别为failover的总次数，以及对同一个源站的错误重试次数。假设源站域名返回的同源ip有三个，前两个ip都不可用，那么如果是前述的配置，源站的访问顺序会是11223，即前两个源站访问两次，第三个源站访问一次，第三个源站访问成功之后返回200，回源才停止。

trafficserver只支持四层代理服务器出错时以及连接超时时启动failover，要支持七层代理服务器的错误，则在源站返回5xx响应码的时候也要启动failover，这要求修改trafficserver源码，将其加补丁，具体在httptransact::handle_response_from_server()函数中添加error_5xx这个case，以在七层代理服务器返回错误响应码时启动failover。

trafficserver源码本身并不支持在回源dns解析中的多个回源ip之间进行failover，这也需要对源码进行修改。

对应于上述方法，如图3所示，是本发明实施例的回源处理装置的结构示意图，所示装置包括：

缓存判断单元21，用于获取用户的查询请求，判断所述查询请求的对象是否存在缓存中；

回源ip确定单元22，用于在不存在缓存的情况下，获取设定个数的回源ip；

对象返回单元23，用于取所述设定个数的回源ip中的一个回源ip进行对象返回；

切换单元24，用于在所述返回的对象出现错误时，根据预先设定条件再次通过该回源ip进行对象返回或者取所述设定个数的回源ip中的下一个回源ip进行对象返回；

控制单元25，用于重复上一步骤，直到所述返回的对象正确、或者前端服务器连接超时、或者所述预先设定条件中的故障切换次数耗尽，结束此次查询请求。

优选地，所述缓存判断单元还用于：在获取用户的查询请求后，通过四层代理服务或者七层代理服务将所述查询请求代理到缓存服务，通过所述缓存服务判断查询请求的对象是否存在缓存中。

优选地，所述回源ip确定单元具体用于：通过后端源站的dns服务产生所述设定个数的回源ip。

优选地，还包括条件设定单元，用于：

通过与http相关的代理和缓存服务设置所述预先设定条件，所述预先设定条件包括每一个回源ip进行对象返回的重复次数以及总的故障切换次数。

优选地，所述条件设定单元还用于：

通过与http相关的代理和缓存服务的故障切换failover系统控制同一回源ip重复进行对象返回以及切换不同回源ip进行对象返回。

本申请是针对每一个回源请求进行实时的failover，这种方式可以针对随机的回源错误有良好的效果。每一个随机的回源错误都会实时进行failover，这有效的降低了错误率。而在传统的健康检查方法之中，随机的错误并不会引起健康检查失败，也就无法有效降低错误率。

本申请的技术方案实时将错误的回源请求进行迁移，即回源failover。其次就是这种实时回源failover技术是在与http相关的代理和缓存服务apachetrafficserver的框架之下实现的，这就要求修改apachetrafficserver本身的代码，并且修改之后造成的状态机异常等bug也要进行处理。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrativelogicalblock)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrativecomponents)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd-rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于asic中，asic可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。