大型网站架构系列：负载均衡详解（3）（转）

本次分享大纲

1. 软件负载均衡概述
2. Ngnix负载均衡
3. Lvs负载均衡
4. Haproxy负载均衡
5. 本次分享总结

1、软件负载均衡概述

硬件负载均衡性能优越，功能全面，可是价格昂贵，通常适合初期或者土豪级公司长期使用。所以软件负载均衡在互联网领域大量使用。经常使用的软件负载均衡软件有Nginx，Lvs，HaProxy等。本文参考大量文档，部分为直接拷贝，参考出处见负载均衡详解（4）。

2、Ngnix负载均衡

Ngnix是一款轻量级的Web服务器/反向代理服务器，工做在七层Http协议的负载均衡系统。具备高性能、高并发、低内存使用等特色。是一个轻量级的Http和反向代理服务器。Nginx使用epoll and kqueue做为开发模型。可以支持高达 50,000 个并发链接数的响应。

操做系统：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）

开发语言：C

并发性能：官方支持每秒5万并发，实际国内通常到每秒2万并发，有优化到每秒10万并发的。具体性能看应用场景。

2.1.特色

1.模块化设计：良好的扩展性，能够经过模块方式进行功能扩展。

2.高可靠性：主控进程和worker是同步实现的，一个worker出现问题，会马上启动另外一个worker。

3.内存消耗低：一万个长链接（keep-alive）,仅消耗2.5MB内存。

4.支持热部署：不用中止服务器，实现更新配置文件，更换日志文件、更新服务器程序版本。

5.并发能力强：官方数据每秒支持5万并发；

6.功能丰富：优秀的反向代理功能和灵活的负载均衡策略

2.2.功能

2.2.1基本功能

• 支持静态资源的web服务器。
• http,smtp,pop3协议的反向代理服务器、缓存、负载均衡；
• 支持FASTCGI（fpm）
• 支持模块化，过滤器（让文本能够实现压缩，节约带宽）,ssl及图像大小调整。
• 内置的健康检查功能
• 基于名称和ip的虚拟主机
• 定制访问日志
• 支持平滑升级
• 支持KEEPALIVE
• 支持url rewrite
• 支持路径别名
• 支持基于IP和用户名的访问控制。
• 支持传输速率限制，支持并发数限制。

2.2.2扩展功能

2.2.3性能

Nginx的高并发，官方测试支持5万并发链接。实际生产环境能到2-3万并发链接数。10000个非活跃的HTTP keep-alive 链接仅占用约2.5MB内存。三万并发链接下，10个Nginx进程，消耗内存150M。淘宝tengine团队测试结果是“24G内存机器上，处理并发请求可达200万”。

2.3架构

2.3.1Nginx的基本工做模式

 

一个master进程，生成一个或者多个worker进程。可是这里master是使用root身份启动的，由于nginx要工做在80端口。而只有管理员才有权限启动小于低于1023的端口。master主要是负责的做用只是启动worker，加载配置文件，负责系统的平滑升级。其它的工做是交给worker。那么当worker被启动以后，也只是负责一些web最简单的工做，而其余的工做都是有worker中调用的模块来实现的。

模块之间是以流水线的方式实现功能的。流水线，指的是一个用户请求，由多个模块组合各自的功能依次实现完成的。好比：第一个模块只负责分析请求首部，第二个模块只负责查找数据，第三个模块只负责压缩数据，依次完成各自工做。来实现整个工做的完成。

他们是如何实现热部署的呢？实际上是这样的，咱们前面说master不负责具体的工做，而是调用worker工做，他只是负责读取配置文件，所以当一个模块修改或者配置文件发生变化，是由master进行读取，所以此时不会影响到worker工做。在master进行读取配置文件以后，不会当即的把修改的配置文件告知worker。而是让被修改的worker继续使用老的配置文件工做，当worker工做完毕以后，直接当掉这个子进程，更换新的子进程，使用新的规则。

2.3.2Nginx支持的sendfile机制

Sendfile机制，用户将请求发给内核，内核根据用户的请求调用相应用户进程，进程在处理时须要资源。此时再把请求发给内核（进程没有直接IO的能力），由内核加载数据。内核查找到数据以后，会把数据复制给用户进程，由用户进程对数据进行封装，以后交给内核，内核在进行tcp/ip首部的封装，最后再发给客户端。这个功能用户进程只是发生了一个封装报文的过程，却要绕一大圈。所以nginx引入了sendfile机制，使得内核在接受到数据以后，再也不依靠用户进程给予封装，而是本身查找本身封装，减小了一个很长一段时间的浪费，这是一个提高性能的核心点。

 

以上内容摘自网友发布的文章，简单一句话是资源的处理，直接经过内核层进行数据传递，避免了数据传递到应用层，应用层再传递到内核层的开销。

目前高并发的处理，通常都采用sendfile模式。经过直接操做内核层数据，减小应用与内核层数据传递。

2.3.3Nginx通讯模型（I/O复用机制）

开发模型：epoll和kqueue。

支持的事件机制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。

支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用数据的数量，错误代码.

支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.

以上概念较多，你们自行百度或谷歌，知识领域是网络通讯（BIO,NIO,AIO）和多线程方面的知识。

2.4均衡策略

nginx的负载均衡策略能够划分为两大类：内置策略和扩展策略。内置策略包含加权轮询和ip hash，在默认状况下这两种策略会编译进nginx内核，只需在nginx配置中指明参数便可。扩展策略有不少，如fair、通用hash、consistent hash等，默认不编译进nginx内核。因为在nginx版本升级中负载均衡的代码没有本质性的变化，所以下面将以nginx1.0.15稳定版为例，从源码角度分析各个策略。

2.4.1. 加权轮询（weighted round robin）

轮询的原理很简单，首先咱们介绍一下轮询的基本流程。以下是处理一次请求的流程图：

 

图中有两点须要注意，第一，若是能够把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其余机器低，才开始将请求分给下一个高权重的机器；第二，当全部后端机器都down掉时，nginx会当即将全部机器的标志位清成初始状态，以免形成全部的机器都处在timeout的状态，从而致使整个前端被夯住。

2.4.2. ip hash

ip hash是nginx内置的另外一个负载均衡的策略，流程和轮询很相似，只是其中的算法和具体的策略有些变化，以下图所示：

 

2.4.3. fair

fair策略是扩展策略，默认不被编译进nginx内核。其原理是根据后端服务器的响应时间判断负载状况，从中选出负载最轻的机器进行分流。这种策略具备很强的自适应性，可是实际的网络环境每每不是那么简单，所以要慎用。

2.4.4 通用hash、一致性hash

这两种也是扩展策略，在具体的实现上有些差异，通用hash比较简单，能够以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，能够支持memcache。

2.5场景

Ngnix通常做为入口负载均衡或内部负载均衡，结合反向代理服务器使用。如下架构示例，仅供参考，具体使用根据场景而定。

2.5.1入口负载均衡架构

 

Ngnix服务器在用户访问的最前端。根据用户请求再转发到具体的应用服务器或二级负载均衡服务器（LVS）

2.5.2内部负载均衡架构

 

LVS做为入口负载均衡，将请求转发到二级Ngnix服务器，Ngnix再根据请求转发到具体的应用服务器。

2.5.3Ngnix高可用

 

分布式系统中，应用只部署一台服务器会存在单点故障，负载均衡一样有相似的问题。通常可采用主备或负载均衡设备集群的方式节约单点故障或高并发请求分流。

Ngnix高可用，至少包含两个Ngnix服务器，一台主服务器，一台备服务器，之间使用Keepalived作健康监控和故障检测。开放VIP端口，经过防火墙进行外部映射。

DNS解析公网的IP实际为VIP。