高性能web站点--负载均衡

负载均衡

这个话题是高性能站点的必备话题

所谓负载均衡就是将负载尽量的均衡分摊到多个不同的服务单元（比如现在我们讲的就是后台服务器），来保证我们服务的可用性，可靠性，提供用户最好的用户体验。

简单手工选择

这个场景，我们在下载某个资源的时候会经常看到。比如下载一个软件，会让我们选择网通，电信，等等

dns 轮询

对于大型网站的域名，多数都对同一个主机添加了多条A记录，这样实现简单的DNS轮询。DNS服务器将解析请求按照A记录的顺序，随机分配到不同的IP地址上，这样来实现最简单的负载均衡。

这样实现的价格非常低，但是不可靠。有两个非常明显的缺点。

1. 可靠性低：

假设一个域名DNS轮询多台服务器，其中一台发生故障，那么所有分配到访问这台服务器的请求都会出错。就算DNS去掉了该服务器的IP，但是由于现在Internet上，各地电信，网通等宽带接入商将很多的DNS放在缓存中，以节省缓存时间，这就导致DNS生效的时间是不确定的。

1. 负载不均衡：

DNS负载均衡采用的是简单的轮询算法， 不能区分服务器的差异， 不能得知反映到服务器的当前运行状态，所以也就做不到为性能好的服务器多分配请求。DNS服务器按照一定的层次结构的，其实就是倒挂树的结构， 本地DNS服务器会缓冲已经解析了的域名和IP的映射， 还有本地计算机也会缓存解析映射， 这些就导致DNS服务器的用户在一段时间内访问的都是同一台web服务器。这会导致的结果是：某几台服务器负额 很低， 某几台负额很高， 负载不均衡。 因此， DNS轮询方式仅仅适用在可靠性要求不高的服务器集群， 比如一些静态的网页服务器集群， 图片服务器集群。

加权轮询

直观理解就是计算当前各个后端服务器的当前权值，然后选择得分最高的服务器处理当前请求，这里我们可能要考虑一些细节，比如多少次连接失败会使得服务器不能参加被选择，时间又是多少？

这种方式有一个明显的缺点，就是session会话机制的问题。比如现在我们使用nginx反向代理的三台服务器A，B，C。如果按照当前权重

A=54, B=13, C=52,

这个时候客户端来的请求，自然会分配给A服务器处理，分配之后，会改变当前权重。

比如：这个时候

A=50, B=13, C=52,

那么就会把这次请求分配给了C服务器，这样就带来一个问题，就是前面建立的session数据还在A服务器上，C服务器并没有这次请求的任何状态，也就是说丢失了会话状态。当然，如果三台服务器共用session数据，那么也可以保持用户的会话状态。

ip_hash

这个方式是利用哈希运算，计算当前用户访问的服务器地址，然后直接分配到该服务器，以后再次请求的话，会直接分配到该同一个服务器上的。

这里就要求我们的散列函数必须是非常均衡的，能够考虑到服务器负载均衡。nginx散列函数把客户的ip，和服务器的状态都考虑进去了。

这里相比加权轮询有一个特点，能够保持用户会话。也就是同一个用户经过一次散列之后，以后总能分配到同一个服务器上。

博客站点：www.ccooa.net