一种配置共享缓存服务器组的方法、装置、设备及介质与流程

文档序号:20678308发布日期:2020-05-08 18:07阅读:219来源:国知局
一种配置共享缓存服务器组的方法、装置、设备及介质与流程

本申请是2018年03月22日提交中国国家知识产权局专利局、申请号为201810238424.x、发明名称为“服务器数据缓存方法、装置和系统”的中国专利申请的分案申请。

本发明涉及计算机网络领域,尤其涉及一种配置共享缓存服务器组的方法、装置、设备及介质。



背景技术:

在缓存(cache)服务器集群中通常使用switch软件分散后端流量,当有流量过热集中在集群中的某台switch服务器上时,通常会将请求均匀分摊打散到后端的缓存服务器上,此时没有缓存相应数据的缓存服务器会直接回二级缓存取数据或者回源,占用大量带宽,有可能将源站或者二级缓存拖垮。

常见服务集群架构如图1所示。以某次热点url跑满网卡为例,现有技术主要注意点集中在将该热点url打散分布到该组后端的所有缓存服务器上,打散后的架构如图2所示。

现有技术存在如下问题:

1、针对该url之前该组缓存数据对于同组其他机器属于无效缓存。降低资源利用率。

2、当cache服务器没缓存相应数据时,将回二级缓存或者源站拉取数据,造成带宽浪费。当打散分散后涉及的cache服务器数量较大时极有可能跑满二级缓存或者源站的带宽,严重时将造成源站宕机,服务不可用。

3、面对突发的流量没有预先准备,临时打散调度存在时间延迟,打散生效需要至少15分钟以上,解决困境效果不佳。

4、打散后cache服务器需重新回源取数据,此时面临跨网跨省网络缓慢,甚至链路中断等问题,影响客户体验。



技术实现要素:

本发明旨在解决上面描述的问题。

根据本发明的第一方面,提供了一种服务器数据缓存方法,包括:

在检测到符合预置的分流条件的统一资源定位符url访问请求时,以太网设备为所述url访问请求配置共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器;

所述以太网设备通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据。

优选的,该方法还包括:

所述以太网设备检测后端的缓存服务器的工作情况,与其他以太网设备同步对所述缓存服务器的工作情况的探测结果。

优选的,所述以太网设备为所述url访问请求配置共享缓存服务器组的步骤包括:

配置本机对应的缓存服务器为所述第一缓存服务器;

根据预置的共享缓存算法,确定其他分配到所述url访问请求的以太网设备;

配置所述其他分配到所述url访问请求的以太网设备对应的且工作情况为正常的缓存服务器为所述第二缓存服务器。

优选的,所述以太网设备通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据的步骤包括:

所述以太网设备将所述第一缓存服务器的ip地址发送至各个所述第二缓存服务器。

根据本发明的另一方面,还提供了一种服务器数据缓存方法,包括:

缓存服务器在接收到url访问请求时,检查所述url的共享缓存服务器组配置;

在本机被配置为第二缓存服务器时,所述缓存服务器向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

优选的,缓存服务器在接收到url访问请求时,检查所述url的共享缓存服务器组配置的步骤之后,还包括:

在本机未被配置入所述url的共享缓存服务器组时,向二级缓存或源数据站进行回源操作,获取缓存数据。

优选的,该方法还包括:

接收以太网设备发送的通知,所述通知包含对所述共享缓存服务器组的配置。

根据本发明的另一方面,还提供了一种服务器数据缓存装置,包括:

共享缓存配置模块,用于在检测到符合预置的分流条件的url访问请求时,为所述url访问请求配置共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器;

配置下发模块,用于通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据。

优选的,该装置还包括:

资源探测模块,用于缓存检测后端的缓存服务器的工作情况;

资源信息同步模块,用于与其他以太网设备同步对所述缓存服务器的工作情况的探测结果。

根据本发明的另一方面,还提供了一种服务器数据缓存装置,包括:

共享配置确定模块,用于在接收到url访问请求时,检查所述url的共享缓存服务器组配置;

缓存数据获取模块,用于在本机被配置为第二缓存服务器时,向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

优选的,所述缓存数据获取模块,还用于在本机未被配置入所述url的共享缓存服务器组时,向二级缓存或源数据站进行回源操作,获取缓存数据。

根据本发明的另一方面,还提供了一种服务器数据缓存系统,包括至少一台以太网设备及各以太网设备对应的缓存服务器;

所述以太网设备,用于在检测到符合预置的分流条件的url访问请求时,为所述url访问请求配置所述共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器,

通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据;

所述缓存服务器,用于在接收到url访问请求时,检查所述url的共享缓存服务器组配置,并在本机被配置为第二缓存服务器时,向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

本发明提供了一种服务器数据缓存方法、装置和系统,在检测到符合预置的分流条件的url访问请求时,以太网设备为所述url访问请求配置共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器,所述以太网设备通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据,形成了只需要回二级缓存或回源拉取一次缓存数据,在多台分流的缓存服务器间共享缓存数据的网络架构。解决了多台缓存服务器拉取二级缓存或回源造成的带宽资源消耗过大、时间延迟的问题,实现了快速高效、稳定可靠的访问热点负载均衡,合理利用组内缓存的优势,同组机器基本在同一交换机网络下,不跨网,速度更快不占用节点出口带宽。

参照附图来阅读对于示例性实施例的以下描述,本发明的其他特性特征和优点将变得清晰。

附图说明

并入到说明书中并且构成说明书的一部分的附图示出了本发明的实施例,并且与描述一起用于解释本发明的原理。在这些附图中,类似的附图标记用于表示类似的要素。下面描述中的附图是本发明的一些实施例,而不是全部实施例。对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,可以根据这些附图获得其他的附图。

图1示例性地示出了现有的服务器集群架构;

图2示例性地示出了现有的打散分布缓存的系统架构;

图3示例性地示出了本发明的实施例一提供的一种服务器数据缓存方法的流程;

图4示例性地示出了本发明的实施例二提供的一种服务器数据缓存系统的架构;

图5示例性地示出了本发明的实施例三提供的一种服务器数据缓存装置的结构;

图6示例性地示出了本发明的实施例三提供的又一种服务器数据缓存装置的结构;

图7示例性地示出本发明的实施例三提供的一种服务器数据缓存系统的架构。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。

现有技术存在如下问题:

1、针对该url之前该组缓存数据对于同组其他机器属于无效缓存。降低资源利用率。

2、当cache服务器没缓存相应数据时,将回二级缓存或者源站拉取数据,造成带宽浪费。当打散分散后涉及的cache服务器数量较大时极有可能跑满二级缓存或者源站的带宽,严重时将造成源站宕机,服务不可用。

3、面对突发的流量没有预先准备,等到热点url发生时再进行打散的配置处理,时间延迟且效率底下,而且配置操作繁琐,解决困境效果不佳。

4、打散后cache服务器需重新回源取数据,此时面临跨网跨省网络缓慢,甚至链路中断等问题,影响客户体验。

为了解决上述问题,本发明的实施例提供了一种服务器数据缓存方法、装置和系统。为热点url访问请求配置一组共享缓存服务器,利用已经缓存了数据的第一缓存服务器作为缓存数据的数据源,其他共享缓存服务器组中的第二缓存服务器向该第一缓存服务器请求其缓存的数据,对第一缓存服务器缓存的数据进行了最大程度的利用,有效的解决了多台缓存服务器拉取二级缓存或回源造成的带宽资源消耗过大、时间延迟的问题,实现了快速高效、稳定可靠的访问热点负载均衡。

首先结合附图,对本发明的实施例一进行说明。

本发明实施例提供了一种服务器数据缓存方法,使用该方法对热点url的流量进行打散缓存处理的流程如图3所示,包括:

步骤301、以太网设备检测后端的缓存服务器的工作情况,与其他以太网设备同步对所述缓存服务器的工作情况的探测结果;

本发明实施中,所述以太网设备具体为switch服务器,缓存服务器具体可为cache服务器或具有缓存功能的tengine服务器、squid服务器等其他服务器。本步骤中以cache服务器为例进行说明,具体如下:

1、switch服务器判断该url访问请求是否配置本机hash和共享缓存配置(表明该url访问请求是否支持共享缓存服务器组)。如果没有则以默认模式继续工作。如果存在共享缓存配置,则进入下一步。

2、各台switch服务器的内部维护一个后端cache服务器的探活池,其中包含可用的全部cache服务器。每个探测周期探测一次各个cache服务器的工作情况(如:服务端口是否正常),将探测结果为不正常的cache服务器从该探活池库中剔除,并同步到其他switch服务器。

switch定义分发后端为本组hash或者本机hash方式,且计算公式存放在proxy模块之后,不能够完成自定义功能。因为共享缓存服务器组内缓存必须计算出本组中存在缓存的那台机器ip,于是需要将该算法抽出,同时还要匹配后端探活功能同时同步一个组内链接表,保证组内其他switch做url本机hash时不会出现问题,避免将url访问请求hash到已经宕机的cache服务器上或者流量跑满的cache服务器上。

需要说明的是,本步骤与后续各步骤并无严格时序关系,对后端cache服务器的探测可持续进行,随时同步更新。

步骤302、在检测到符合预置的分流条件的url访问请求时,以太网设备为所述url访问请求配置共享缓存服务器组;

本发明实施例中,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器。所述第一缓存服务器与所述第二缓存服务器均为相同的缓存服务器,只是在配置到同一共享缓存服务器组中时,第一缓存服务器作为指定缓存服务器,可进行回源或拉取二级缓存的操作以获得缓存数据,第二缓存服务器则自该第一缓存服务器获取缓存数据。同一缓存服务器在不同url访问请求的共享缓存服务器组的配置中可能作为第一缓存服务器,也可能作为第二缓存服务器。本发明的实施例还提供了一种服务器数据缓存系统,架构如图4所示,switch服务器分发url访问请求,共享缓存服务器组共享缓存数据,lvs负载均衡系统作为前端负载均衡系统,能在一定情况下将请求均匀的发布到switch服务器上。多台switch服务器构成switch分发请求系统,计算出后端共享cache服务器组中存在第一缓存服务器,将该第一缓存服务器的ip地址发送给其他第二缓存服务器,是组内共享缓存配置部分。共享cache服务器组内的第二缓存服务器根据switch服务器发送的信息,向同组第一缓存服务器取回数据。二级缓存作为缓存缓冲系统,减轻回源压力。将热点url访问请求打散后,采用分布式结构,配置热点url为组内共用缓存模式,直接提高每台cache服务器的承载能力,在发生热点url之前解决问题。

本步骤具体包括:

1、配置本机对应的缓存服务器为所述第一缓存服务器;

2、根据预置的共享缓存算法,确定其他分配到所述url访问请求的以太网设备;

3、配置所述其他分配到所述url访问请求的以太网设备对应的且工作情况为正常的缓存服务器为所述第二缓存服务器。

符合分流条件的url访问请求也可称为热点url,是通过业务确认的。可以是客户告知,例如今天要做活动某个页面的请求会非常大。或者该url请求数非常大,将服务器进程、cpu资源等耗尽,也认为是热点url。

步骤303、所述以太网设备通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据。

所述以太网设备将所述第一缓存服务器的ip地址发送至各个所述第二缓存服务器。

仍以图4所示架构为例进行说明,switch服务器调用一致性hash模块计算出之前存在缓存数据的那台第一缓存服务器的ip地址,并设置一个头部share_loop:ip通过各switch服务器给各台cache服务器。将之前算法提取出来,然后将同步的地址池作为输入数据,计算出一个第一缓存服务器的ip,将该ip通知给各cache服务器,这样能保证同一共享缓存服务器组中的第二缓存服务器全部到第一缓存服务器取数据。

步骤304、缓存服务器接收以太网设备发送的通知;

本步骤中,所述通知包含对所述共享缓存服务器组的配置。根据该配置,能够确定本缓存服务器的身份为第一缓存服务器或第二缓存服务器。进一步的,该通知为一个头部share_loop:ip,携带有第一缓存服务器的ip地址。

缓存服务器将通知指示的ip保存起来。例如,可通过定义dynamic_catch模块将头部中的ip信息取出来,并存在变量cacheip中。

步骤305、缓存服务器在接收到url访问请求时,检查所述url的共享缓存服务器组配置;

本步骤中,在接收到url访问请求时,逻辑判断该条url的数据是否已经存在本机缓存,如果有直接返回数据数据。若本机不存在与该url关联的缓存数据,在本机被配置为第二缓存服务器时,所述缓存服务器向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。具体的,在本机中保存有第一缓存服务器的ip地址且本机非第一缓存服务器时,进入步骤306,向该ip地址请求缓存数据。在本机中没有共享缓存服务器组配置或本机即为第一缓存服务器时,进入步骤307拉取数据。

仍以步骤304中的举例为例进行说明,cache服务器的动态填充cache_src功能模块获取cacheip变量值,通过cache之间的探活功能确认该ip服务正常,否则直接回上级节点取得缓存。

步骤306、在本机被配置为第二缓存服务器时,所述缓存服务器向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

仍以步骤304中的举例为例进行说明,本步骤中,缓存服务器的cache_request模块向cacheip中存放的ip地址发起类似回源请求,取回数据同时不传递share_loop头,避免引起死循环。

步骤307、在本机未被配置入所述url的共享缓存服务器组时,向二级缓存或源数据站进行回源操作,获取缓存数据。

下面结合附图,对本发明的实施例二进行说明。

本发明提供了一种服务器数据缓存系统,其架构如图4所示,该系统在预知热点url存在情况下或者临时突发热点的url情况下,需修改url加上组内共享缓存配置和本机hash设置,为该url配置共享服务器组。

s1:热点url通过lvs前端负载均衡在一定程度上平均分布到switch服务器上。假设落在b服务器上。

s2:此时switch检测该url配置了本机hash算法和组内共享缓存,于是在系统中计算出两个值(本机hash值,确定将请求发送到d。同时计算出本组hash值即存在有缓存的一台服务器假设是a)。

s3:此时switch系统将请求直接传递给ecache服务器,同时带上一个share-loop:d_ip的头部值(share_loop表示告诉cache启用组内共享缓存功能,d_ip为计算出来存在缓存的d服务器)。

s4:bcache服务器首先内部判断是否存在该url的缓存,如果有直接返回数据。如果没有,则取出share_loop中的d_ip,并同步向dcache服务器请求数据。

s5:bcache在内网中快速获取数据,并缓存一份,直接解决需要回二级缓存或者源站取数据的问题。

下面结合附图,对本发明的实施例三进行说明。

本发明实施例提供了一种服务器数据缓存装置,其结构如图5所示,包括:

共享缓存配置模块501,用于在检测到符合预置的分流条件的url访问请求时,为所述url访问请求配置共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器;

配置下发模块502,用于通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据。

优选的,该装置还包括:

资源探测模块503,用于缓存检测后端的缓存服务器的工作情况。

优选的,该装置还包括:

资源信息同步模块504,用于与其他以太网设备同步对所述缓存服务器的工作情况的探测结果。

图5所示的服务器数据缓存装置,可集成于以太网设备中,由以太网设备实现相应功能。

一种服务器数据缓存装置,其结构如图6所示,包括:

共享配置确定模块601,用于在接收到url访问请求时,检查所述url的共享缓存服务器组配置;

缓存数据获取模块602,用于在本机被配置为第二缓存服务器时,向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

优选的,所述缓存数据获取模块602,还用于在本机未被配置入所述url的共享缓存服务器组时,向二级缓存或源数据站进行回源操作,获取缓存数据。

如图6所示的服务器数据缓存装置,可集成于缓存服务器上,由缓存服务器实现相应功能。

本发明实施例还提供了一种服务器数据缓存系统,其架构如图7所示,包括至少一台以太网设备及各以太网设备对应的缓存服务器;

所述以太网设备,用于在检测到符合预置的分流条件的url访问请求时,为所述url访问请求配置所述共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器,

通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据;

所述缓存服务器,用于在接收到url访问请求时,检查所述url的共享缓存服务器组配置,并在本机被配置为第二缓存服务器时,向所述共享缓存服务器组中的第一缓存服务器获取所述url访问请求的缓存数据。

本发明的实施例提供了一种服务器数据缓存方法、装置和系统,在检测到符合预置的分流条件的url访问请求时,以太网设备为所述url访问请求配置共享缓存服务器组,所述共享缓存服务器组包含一台第一缓存服务器和至少一台第二缓存服务器,所述以太网设备通知各台所述第二缓存服务器通过所述第一缓存服务器获取所述url访问请求的缓存数据,形成了只需要回二级缓存或回源拉取一次缓存数据,在多台分流的缓存服务器间共享缓存数据的网络架构。解决了多台缓存服务器拉取二级缓存或回源造成的带宽资源消耗过大、时间延迟的问题,实现了快速高效、稳定可靠的访问热点负载均衡,合理利用组内缓存的优势,同组机器基本在同一交换机网络下,不跨网,速度更快不占用节点出口带宽。

上面描述的内容可以单独地或者以各种方式组合起来实施,而这些变型方式都在本发明的保护范围之内。

最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制。尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1