随着访问量的上升,web 系统的压力越来越大,在这个过程中,面临很多问题。 而在网络层面上,由于数据暴增,单服务器开始疲于应对海量用户访问,就需要搭建负载均衡系统,让分布式集群分担压力。 所谓的负载均衡,就是让服务器集群分配工作任务,起到保护 web 服务器的作用。
而负载均衡的策略很多,主要有以下几个:
网页通过 301、302 返回包含 Location 的请求包头,让浏览器再次发起请求,访问新的 URL,通过重定向,实现了负载均衡的效果。 例如,当我们下载 PHP 源码包的时候,点击下载链接,会被重定向到离我们最近的 URL 下载地址进行下载。
但是由于这个方案的每次访问实际进行了两次访问,增加了网络延时,降低了用户体验,同时,在大规模访问的情况下,也会出现性能不佳。
nginx 作为一种常见的反向代理服务器,在负载均衡中常常会被使用。 反向代理服务器的核心任务是转发 HTTP 请求,扮演了服务器与用户数据中转的角色。 由于反向代理服务器是在应用层工作,是 OSI 网络七层结构中的第七层,所以也被称为“七层负载均衡”。 当然,除 nginx 外,可以做反向代理的软件还有很多,但 nginx 可以灵活制定转发策略,分配服务器流量的权重。
但是,由于每台服务器单独存储了用户的 session 数据,无法保证登录用户能够找到 session,而导致重复登录的现象。 有下面两种解决方案: 1. 配置转发规则,让同一个用户的请求一定使用同一台服务器处理,但是这样的规则不仅无法实现严格的负载均衡,对代理服务器来说也具有很大的负担 2. 将 session 等信息保存在某个独立服务来存储,如使用 redis、memcache 等,该方案较为常用
由于 IP 负载均衡工作在网络层和传输层,所以也被称为“四层负载均衡”。 相比于工作在应用层的反向代理负载均衡,其工作性能要高很多。
IP 负载均衡对 IP 层数据包的 IP 地址和端口信息进行修改,以便让请求定位到具体的某个服务器 IP,实现重定向和负载均衡的目的。 这种负载均衡最常见的实现方式就是 LVS (Linux Virtual Server),意即“Linux 虚拟服务”,通过 IPVS 实现。
负载均衡服务器收到 IP 包后,会修改 IP 包的目标 IP 地址和端口,然后原封不动的投递到内部网络中,最终流入到实际的 web 服务器。 当实际 web 服务器处理完请求后,负载均衡服务器又会将 IP 包中的 IP 地址和端口修改为用户 IP 地址,最终返回客户端。
上述的方式叫 LVS-NAT,除此之外,还有LVS-RD(直接路由),LVS-TUN(IP 隧道),三者之间都属于 LVS 的方式。
IP 负载均衡的性能要高出Nginx的反向代理很多,它只处理到传输层为止的数据包,并不做进一步的组包,然后直接转发给实际服务器。 但是它的配置和搭建比较复杂。
DNS 服务器即内容分发服务器,他存储了 IP 地址与域名的对应关系,它可以使用 GSLB(全局负载均衡)实现负载均衡。 DNS 服务器将一个域名映射到多个 IP,GSLB 根据 DNS 服务器的 IP 返回一个距离请求者最近的 IP 地址。 这种方式不仅性能很好,而且可以配置多种策略。
类似的,也应用在 CDN 实现的负载均衡: CDN 在 Web 系统中,一般情况下是用来解决大小较大的静态资源(html/Js/Css/图片等)的加载问题,让这些比较依赖网络下载的内容,尽可能离用户更近,可以很大程度的提升用户体验。 但是,搭建和维护成本非常高。互联网一线公司,会自建CDN服务,中小型公司一般使用第三方提供的CDN。
一般来说,具体的方案选择可以遵循:
[3:8] | 日访问量 | 方案选择 |
---|---|---|
百万以下 | 单机优化数据库 | |
百万到千万 | nginx 负载均衡,mysql 读写分离 | |
千万以上 | lvs,使用 nosql | |
亿级 | 异地部署,多种方案结合 |
http://www.csdn.net/article/2014-11-06/2822529