著录项信息
专利名称 | 一种应用于三层网络的负载均衡方法和系统 |
申请号 | CN200910130317.6 | 申请日期 | 2009-03-26 |
法律状态 | 权利终止 | 申报国家 | 中国 |
公开/公告日 | 2010-09-29 | 公开/公告号 | CN101848137A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L12/56 | IPC分类号 | H;0;4;L;1;2;/;5;6查看分类表>
|
申请人 | 北京快网科技有限公司 | 申请人地址 | 北京市朝阳区八里庄西里100号住邦2000商务中心1号楼A605室
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 北京快网科技有限公司 | 当前权利人 | 北京快网科技有限公司 |
发明人 | 刘再德;郝冲 |
代理机构 | 北京邦信阳专利商标代理有限公司 | 代理人 | 崔华 |
摘要
本发明公开了一种应用于三层CDN网络的负载均衡方法,所述三层CDN网络包括DNS层、Proxy层和Cache层,所述方法包括:在DNS层解析请求方的域名;在Proxy层根据URL内容对所述URL请求进行分组;将分组的URL请求定向到Cache层中的相应服务器。本发明还公开了一种应用于三层网络的负载均衡系统,所述系统包括:接收解析模块、URL分组模块和定向模块。采用本发明的负载均衡方法和系统,每个URL内容只缓存一次,大大节省了磁盘存储空间;而且,可以充分利用多个Cache实例,从而提高的CPU的利用率。
1.一种应用于三层CDN网络的负载均衡方法,所述三层CDN网络包括DNS层、Proxy层和Cache层,其特征在于,所述方法包括:
a.位于DNS层的服务器中的接收解析模块在DNS层接收并解析用户的URL请求的域名;
b.位于Proxy层的服务器中的URL分组模块在Proxy层根据URL内容对所述URL请求进行分组;
c.位于Proxy层的服务器中的定向模块将分组的URL请求定向到Cache层中的相应服务器,以使相同的URL内容被分配给同一个Cache层服务器。
2.根据权利要求1所述的方法,其特征在于,在步骤b,在Proxy层根据URL内容的首字符对所述URL请求进行分组。
3.根据权利要求1或2所述的方法,其特征在于,在步骤b和步骤c之间还包括:
b1.根据服务器的负载状况调整步骤b中的URL请求分组。
4.根据权利要求3所述的方法,其特征在于,步骤b1包括:将负载超过预定流量的Cache层服务器组进一步分拆为一个或多个组。
5.一种应用于三层网络的负载均衡系统,其特征在于,所述系统包括:接收解析模块、URL分组模块和定向模块,其中,
接收解析模块,位于DNS层的服务器中,用于接收并解析终端用户URL请求中的域名;
URL分组模块,位于Proxy层的服务器中,用于根据URL内容对所述URL请求进行分组;
定向模块,位于Proxy层的服务器中,用于将分组的URL请求定向到Cache层中的相应服务器,以使相同的URL内容被分配给同一个Cache层服务器。
6.根据权利要求5所述的负载均衡系统,其特征在于,URL分组模块用于在Proxy层根据URL内容的首字符对所述URL请求进行分组。
7.根据权利要求5或6所述的负载均衡系统,其特征在于,还包括第二分组模块,所述第二分组模块位于Proxy层的服务器中,用于将负载超过预定流量的Cache层服务器组进一步分拆为一个或多个组。
一种应用于三层网络的负载均衡方法和系统\n技术领域\n[0001] 本发明涉及网络通信领域,尤其涉及一种应用于三层网络的负载均衡方法。\n背景技术\n[0002] CDN技术是近年来迅速发展起来的一种解决互联网性能不佳问题的有效手段。\nCDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。CDN的全称是Content Delivery Network,即内容分发网络。总的来说,内容服务基于很多缓存服务器(Cache servers),部署在多个地方,位于网络的边缘,与用户端很近。缓存服务器可以看成是内容提供商源服务器的透明镜像,从而可以使用户快速地获得其需要访问的资源。\n[0003] 在基于http协议的网络应用中,用户可以通过输入标识网络地址的URL(统一资源定位符)来对缓存服务器上的各种网络资源进行访问。由于访问量通常很大而网络资源有限,网络系统通常需要对用户的URL访问请求的处理进行分配,即进行负载均衡,将接收到的URL请求转移到不同的服务器上执行。\n[0004] 但在现有技术的负载均衡方案中,更多的是只根据服务器的负载状况对URL请求进行分配处理,这类方案容易造成的问题是:对于多个URL内容请求,可能同一个URL内容会被转发并缓存到多个服务器上,造成同一内容在这些服务器上的重复存储。这会造成服务器群存储空间的浪费,降低了硬件资源的利用率,而且命中率不高。\n[0005] 发明内容\n[0006] 本发明的目的是针对现有技术的缺陷,提供一种能够高效利用服务器的负载均衡方法和系统。\n[0007] 本发明提供的负载均衡方法包括:a.在DNS层接收并解析用户的URL请求中的域名;b.在Proxy层根据URL内容对所述URL请求进行分组;c.将分组的URL请求定向到Cache层中的相应服务器。\n[0008] 优选地,在步骤b,在Proxy层根据URL内容的首字符对所述URL请求进行分组。\n[0009] 优选地,在步骤b和步骤c之间还包括:b1.根据服务器的负载状况调整步骤b中的URL分组。\n[0010] 优选地,步骤b1包括:将负载超过预定流量的服务器组进一步分拆为一个或多个组。\n[0011] 本发明提供的负载均衡系统包括:接收解析模块、URL分组模块和定向模块,其中,接收解析模块,位于DNS层的服务器中,用于接收并解析终端用户的URL请求中的域名;\nURL分组模块,位于Proxy层的服务器中,用于根据URL内容对所述URL请求进行分组;定向模块,位于Proxy层的服务器中,用于将分组的URL请求定向到Cache层中的相应服务器。\n[0012] 优选地,URL分组模块用于在Proxy层根据URL内容的首字符对所述URL请求进行分组。\n[0013] 优选地,还包括第二分组模块,所述第二分组模块位于Proxy层的服务器中,用于将负载超过预定流量的服务器组进一步分拆为一个或多个组。\n[0014] 优选地,所述第二分组模块位于Proxy层的服务器中,用于将负载超过预定流量的服务器组进一步分拆为一个或多个组。\n[0015] 采用本发明的负载均衡方法和系统,在全部的Cache服务器群中,每个URL内容只缓存一次,大大节省了磁盘存储空间;而且,可以充分利用多个Cache实例,从而提高的CPU的利用率。本发明可以基于URL进行唯一定位,将同一个URL内容只在对应的Cache上缓存一次,从而大大提高了命中率并解决了由于重复缓存带来的磁盘用量大的问题。\n附图说明\n[0016] 图1是本发明优选实施方式的负载均衡方法的流程图;\n[0017] 图2是本发明优选实施方式的负载均衡系统的结构示意图;\n[0018] 图3是本发明优选实施方式的负载均衡系统的网络拓扑图。\n具体实施方式\n[0019] 如图1所示,根据发明优选实施方式所提供负载均衡方法,在步骤100,首先在DNS层接收并且解析终端用户URL请求中的域名,从而在众多CDN节点中选择最优的CDN节点。\n其中,最优的CDN节点是指离请求的终端用户最近、最合适于处理该请求的某个CDN节点或多个(一般是两个,可以互为备份)CDN节点。例如,根据互联网TCP/IP协议,某个用户在本地主机上运行一个浏览器,用户要将HTTP请求消息发送到名为www.xyz.com的web服务器主机,浏览器必须要先知道www.xyz.com的IP地址。基本每台主机都运行DNS应用的客户端,浏览器从URL中抽取出主机名,将主机名传递给本地主机上的DNS应用客户端。于是DNS客户端向某个DNS服务发出针对www.xyz.com的DNS查询消息。而域名www.xyz.com的“权威”DNS服务器(在本发明中,是位于CDN网络DNS层的某个服务器)最终解析为相对应的IP地址。然后,浏览器打开一个到位于该IP地址的HTTP服务器的TCP连接。由于DNS客户端一般与用户的机器在同一网络区域里。所以可以基本定位用户的位置。在CDN网络平台,DNS层节点的选择算法通常考虑以下三个参数:1)哪个节点里该DNS客户的位置最近;2)哪个节点当前的可用性最高;3)哪个节点当前的负载最轻。\n[0020] 在步骤102,在Proxy层根据URL内容分配所述URL请求。在本发明的优选实施方式中,根据URL内容的首字符进行分组,例如,以0-9开头的URL作为一组、以A-G开头的URL作为另一组等等。可以通过静态Hash算法来实现上述分配,根据内容对URL进行分配可以使相同的URL内容被分配给同一个Cache服务器,从而能够避免同一内容在多个服务器上的重复存储。在本优选实施方式中,是根据URL内容的首字符利用静态Hash算法进行分配,但本领域技术人员应该理解,也可以采用其他适合的针对URL内容的分组规则或分配算法,例如,可以通过URL类来进行分组。\n[0021] 在步骤104,将分组的URL请求定向到Cache层中的相应服务器,从而在最优CDN网络节点上,选择最佳的Cache服务器。将分配的各个URL请求发送给Cache层中的相应缓存服务器上。由于在所述缓存服务器上镜像存储有相应的内容,因此,通过将所述内容传输回用户端,用户端能够访问获得该内容。\n[0022] 优选地,本发明的负载均衡方法再步骤102和步骤104之间还包括步骤103:根据服务器的负载状况调整步骤102中的URL分组。这是因为,在实际应用中,有些URL会非常“热”,即会有很多用户访问某一个或某些URL,因此当将这些URL请求Hash到特定服务器时,会导致“过冷”或“过热”地访问某些服务器,即,有些服务器的负载极大而另一些服务器的负载极小。\n[0023] 因此,在步骤104中,优选地可以动态调整URL的分类。例如:在步骤102中,将原URL包含类分解成0-9、A-Z访问组,当A-Z访问组中的对F-K访问组的访问过“热”时,可以动态调整将F-K拆分成两组或多组,例如拆分为A-H、J-Z组等,从而实现对服务器访问的“热”、“冷”动态均衡。具体地,可以采用动态Hash算法进行上述动态调整,例如:当对某一个或某几个组的访问流量大于某一设定阈值时,通过Hash算法对生成的key和Proxy层配置里的服务器数量做一次求余计算,得到Cache服务器号,以便于后端服务器迅速找到内容对应的Cache Server。其他适合的现有算法也可以用于步骤104的动态调整,例如,可以采用轮叫调度算法(round-robin),有权调度算法(weighted round-robin)等。\n[0024] 在本发明中,将静态Hash和动态Hash算法组合应用:通过在ProxyServer上配置URLhash算法(即静态哈希算法),使访问量根据URL均衡分布到Cache层的各台Cache Server上,根据URL分流之后,每一个URL就会只存在于一台Cache Server中,每台Cache Server的数据都会不同。\n[0025] 将动态Hash算法与静态Hash算法相结合可以减少“冷”内容的缓存空间并增加“热”内容的存储空间。\n[0026] URL hash算法可以使用标准的crc32默认的simple算法。\n[0027] simple算法在java中可利用java.util.zip.CRC32类实现,simple算法的c语言实现如下:\n[0028] #define ngx_hash(key,c)((u_int)key*31 c)\n[0029] u_int ngx_hash_key(u_char*data,size_t len)\n[0030] {\n[0031] u_int i,key;key=0;\n[0032] for(i=0;i<len;i){\n[0033] key*=31;\n[0034] key=data[i];\n[0035] }\n[0036] return key;\n[0037] }\n[0038] 如图2所示,图中示出了优选实施方式中一种应用于三层网络的负载均衡系统\n200,结合图3所示的负载均衡系统网络拓扑图,可以看出,在所述系统中,包括:接收解析模块201、URL分组模块202和定向模块203,在更优选的实施方式中,还包括第二分组模块\n204。\n[0039] 接收解析模块201位于DNS层的服务器中,用于接收用户的URL请求。接收解析模块式DNS服务器的核心部分,以便将用户输入的统一资源定位符解析为IP地址。\n[0040] URL分组模块202位于Proxy层的服务器中,用于根据URL内容对所述URL请求进行分组。URL分组模块202由静态Hash算法实现,分组即是将URL根据其内容(例如其首字符)进行分类,不同类的URL被定向到不同的Cache服务器上。\n[0041] 定向模块203位于Proxy层的服务器中,用于将分组的URL请求定向到Cache层中的相应服务器。定向模块203可以通过Proxy服务器上的软件模块实现。\n[0042] 优选地,在进一步的优选实施方式中还包括第二分组模块204,所述第二分组模块\n204位于Proxy层的服务器中,用于将负载超过预定流量的服务器组进一步分拆为一个或多个组。第二分组模块204不仅由URLHash算法实现,而且包括服务器的负载判别算法,当某一个或某几个服务器的流量超过预定值时,执行URL Hash算法对URL进行重定向。\n[0043] 上述模块优选地通过软件模块实现,但也可以适合的硬件电路或控制逻辑。\n[0044] 尽管本发明是通过上述的优选实施方式进行描述的,但是其实现形式并不局限于上述的实施方式。应该认识到在不脱离本发明主旨的情况下,本领域技术人员可以对本发明做出不同的变化和修改。
法律信息
- 2021-03-12
未缴年费专利权终止
IPC(主分类): H04L 12/56
专利号: ZL 200910130317.6
申请日: 2009.03.26
授权公告日: 2012.11.21
- 2012-11-21
- 2010-11-17
实质审查的生效
IPC(主分类): H04L 12/56
专利申请号: 200910130317.6
申请日: 2009.03.26
- 2010-09-29
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2008-01-30
|
2007-08-23
| | |
2
| |
2008-07-16
|
2007-12-24
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |