为了解决大型网站的访问量大、并发量高、海量数据的问题,我们一般会考虑业务拆分和分布式部署。我们可以把那些关联不太大的业务独立出来,部署到不同的机器上,从而实现大规模的分布式系统。但这之中也有一个问题,那就是用户如何选择相应的机器的问题,这也被称为访问统一入口问题,而解决的方法是我们可以在集群机器的前面增加负载均衡设备,实现流量分发。
负载均衡就是将负载(工作任务、访问请求等)进行平衡、分摊到多个操作单元(服务器、组件等)上进行执行,是解决高性能,单点故障(高可用,如果你是单机版网络,一旦服务器挂掉了,那么用户就无法请求了,但对于集群来说,一台服务器挂掉了,负载均衡器会把用户的请求发送给其他的服务器进行处理),扩展性(这里主要是指水平伸缩)的终极解决方案。
上述所说的负载均衡的设备为nginx:
1、Upstream
负载均衡需要使用Nginx支持的HTTP Upstream模块,该模块通过一个简单的算法调度来实现客户端ip到服务端负载均衡。Upstream目前支持4种调度算法:
A、默认的轮循
默认的调度算法,在处理客户端的每次请求时,按照时间顺序逐一分配到均衡服务器,可以设定服务器的权重(weight)比值,比值越大访问的几率越大,一般用在后台服务器列表访问性能不均匀情况。
B、ip_hash
记录每次访客的ip地址,固定分配给指定的服务器,有效的解决了不同服务器网页Session的问题。
C、fair
根据后端服务器响应的时间长短来分配,响应时间越短被分配几率越大,它属于第三方插件,Nginx本身并不支持,如需使用必须下载Nginx的upstream_fair模块。
D、url_hash
按访问的地址url的hash值结果分配, 使每个url定向到指定的服务器,可以提高后端服务器的缓存效率,同样的,Nginx本身也不支持该算法,需要第三方的hash软件。
2、Upstream支持的状态参数
在Nginx的Upstream模块中,除了可以通过server指定到特定服务器和端口,还可以设置服务器在负载均衡中的状态。目前的状态如下:
A、down
代表当前的服务器server不参与负载均衡。
B、backup
预留的备用设备,也就是当其它的服务器故障或忙时才会分配它给客户请求,所以它的压力最小。
C、max_fails
服务器server允许请求失败的次数,默认为1次,当失败次数超过限定的次数,就会返回proxy_next_upstream错误信息。
D、fail_timeout
当经历了max_fails的次数后,暂停服务的时间,一般与max_fails配合使用。
解决服务器共享session问题:使用redis(之前做过描述)来共享各个服务器的session,并同时通过redis来缓存一些常用的资源,加快用户获得请求资源的速度。