一分钟了解负载均衡的一切

来源: 投稿
作者: 达尔文
2016-09-16

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。

什么是负载均衡

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。

常见的负载均衡方案


常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。

【客户端层->反向代理层】的负载均衡

【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的:DNS-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问DNS-server,会轮询返回这些ip,保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip,以做到每台nginx的请求分配也是均衡的。

【反向代理层->站点层】的负载均衡


【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的。通过修改nginx.conf,可以实现多种负载均衡策略:

1)请求轮询:和DNS轮询类似,请求依次路由到各个web-server

2)最少连接路由:哪个web-server的连接少,路由到哪个web-server

3)ip哈希:按照访问用户的ip哈希值来路由web-server,只要用户的ip分布是均匀的,请求理论上也是均匀的,ip哈希均衡方法可以做到,同一个用户的请求固定落到同一台web-server上,此策略适合有状态服务,例如session(58沈剑备注:可以这么做,但强烈不建议这么做,站点层无状态是分布式架构设计的基本原则之一,session最好放到数据层存储)

4)…

【站点层->服务层】的负载均衡


【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

上一篇文章《RPC-client实现细节》中有详细的负载均衡、故障转移、超时处理的细节描述,欢迎点击link查阅,此处不再展开。

【数据层】的负载均衡

在数据量很大的情况下,由于数据层(db,cache)涉及数据的水平切分,所以数据层的负载均衡更为复杂一些,它分为“数据的均衡”,与“请求的均衡”。

数据的均衡是指:水平切分后的每个服务(db,cache),数据量是差不多的。

请求的均衡是指:水平切分后的每个服务(db,cache),请求量是差不多的。

业内常见的水平切分方式有这么几种:

一、按照range水平切分

每一个数据服务,存储一定范围的数据,上图为例:

user0服务,存储uid范围1-1kw

user1服务,存储uid范围1kw-2kw

这个方案的好处是:

(1)规则简单,service只需判断一下uid范围就能路由到对应的存储服务

(2)数据均衡性较好

(3)比较容易扩展,可以随时加一个uid[2kw,3kw]的数据服务

不足是:

(1)请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大

二、按照id哈希水平切分


每一个数据服务,存储某个key值hash后的部分数据,上图为例:

user0服务,存储偶数uid数据

user1服务,存储奇数uid数据

这个方案的好处是:

(1)规则简单,service只需对uid进行hash能路由到对应的存储服务

(2)数据均衡性较好

(3)请求均匀性较好

不足是:

(1)不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移

总结

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。

(1)【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的

(2)【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的

(3)【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的

(4)【数据层】的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”

(作者:58沈剑,来源:架构师之路

展开阅读全文
300 收藏
分享
加载中
最新评论 (9)
FPE

引用来自“BaiYang”的评论

现在用 DNS 做负载均越来越少,主要缺点在于:
1.负载不够均衡;2.某台 RP down 掉 DNS 无法即时感知并将其排除。现在 LB 更多用 LVS 等方案,通过 vrrp 做冗余,并通过 VIP(在 BGP Routers 上设置同一IP路由的不同优先级条目)做多活 IDC。
谢谢分享。看了一下关于LVS的介绍,看来可以实现IP Tunneling来解决web的负载平衡。非web的其他东西目前的设计跟LVS差不多,也是有调度服务器。不过IP Tunneling的实现似乎比较麻烦
2016-09-17 12:28
0
回复
举报

引用来自“BaiYang”的评论

现在用 DNS 做负载均越来越少,主要缺点在于:
1.负载不够均衡;2.某台 RP down 掉 DNS 无法即时感知并将其排除。现在 LB 更多用 LVS 等方案,通过 vrrp 做冗余,并通过 VIP(在 BGP Routers 上设置同一IP路由的不同优先级条目)做多活 IDC。
说得对
2016-09-17 11:22
0
回复
举报
现在用 DNS 做负载均越来越少,主要缺点在于:
1.负载不够均衡;2.某台 RP down 掉 DNS 无法即时感知并将其排除。现在 LB 更多用 LVS 等方案,通过 vrrp 做冗余,并通过 VIP(在 BGP Routers 上设置同一IP路由的不同优先级条目)做多活 IDC。
2016-09-16 22:34
0
回复
举报
FPE

引用来自“FPE”的评论

虽然我没怎么学习过其他人分布式架构,不过上文跟我写的后台架构大同小异,上文好像是针对web的,我的那个是通用型(包括web、一般程序、文件上传下载、游戏……)

负载平衡策略,DB方面跟上面这一样是使用range划分,World_Server部分(上文的service)使用一个rank计算公式(根据带宽+CPU的负载自动平衡),Packet_Server(上文的nginx)一般根据带宽占用来平衡

上文一些东西以前没想到,比如根据hash划分。但我认为这些东西没有必要,根据带宽占用率和CPU占用率来划分更能准确负载平衡,用hash也不一定能保证是负载一定平衡

引用来自“Nottyjay”的评论

hash算法主要是为了让同一个用户每次都请求同一台主机。一般就是产生了临时数据又不想走第三方缓存时候有这类需要
我的做法是,几乎所有服务(无论是应用程序、文件、还是游戏)都是连Packet_Server(自动选择最快的),后台架构根据需要从World_Server选择服务。理论上web服务器直连也可以,但似乎只能通过DNS轮询进行负载,而DNS轮询不能高效的平衡带宽和CPU占用,暂时也没开始认真想这个问题如何解决
2016-09-16 22:23
0
回复
举报

引用来自“FPE”的评论

虽然我没怎么学习过其他人分布式架构,不过上文跟我写的后台架构大同小异,上文好像是针对web的,我的那个是通用型(包括web、一般程序、文件上传下载、游戏……)

负载平衡策略,DB方面跟上面这一样是使用range划分,World_Server部分(上文的service)使用一个rank计算公式(根据带宽+CPU的负载自动平衡),Packet_Server(上文的nginx)一般根据带宽占用来平衡

上文一些东西以前没想到,比如根据hash划分。但我认为这些东西没有必要,根据带宽占用率和CPU占用率来划分更能准确负载平衡,用hash也不一定能保证是负载一定平衡
hash算法主要是为了让同一个用户每次都请求同一台主机。一般就是产生了临时数据又不想走第三方缓存时候有这类需要
2016-09-16 17:49
0
回复
举报
FPE
虽然我没怎么学习过其他人分布式架构,不过上文跟我写的后台架构大同小异,上文好像是针对web的,我的那个是通用型(包括web、一般程序、文件上传下载、游戏……)

负载平衡策略,DB方面跟上面这一样是使用range划分,World_Server部分(上文的service)使用一个rank计算公式(根据带宽+CPU的负载自动平衡),Packet_Server(上文的nginx)一般根据带宽占用来平衡

上文一些东西以前没想到,比如根据hash划分。但我认为这些东西没有必要,根据带宽占用率和CPU占用率来划分更能准确负载平衡,用hash也不一定能保证是负载一定平衡
2016-09-16 13:22
0
回复
举报
RPC-client实现细节,看看这个
2016-09-16 12:08
0
回复
举报
还不错
2016-09-16 10:38
0
回复
举报
mark
2016-09-16 10:05
0
回复
举报
更多评论
9 评论
300 收藏
分享
返回顶部
顶部