负载均衡概述及优缺点对比

随着用户访问的增多，一个应用服务器不能满足需求了，就需要部署多台应用服务器，通过负载均衡，将数据分发到不同的应用服务器。

从作用来看，和缓存集群的分发很相似，但是有不同。缓存需要发送到特定的服务器。但是，由于应用服务器是无状态的，因此，负载均衡不用根据请求分发到特定服务器，发送到哪个应用服务器都可以。

因此，负载均衡关注的技术焦点有两个，分别是：网络通信、路由选择

网络通信分为以下几种方法。

负载均衡服务器什么都不做，重定向响应

这种方法优点是简单，但是缺点也很明显：

由于这些问题，这种方法，在现实中几乎没有人使用。

每次请求DNS解析到IP地址不同，从而访问到不同到应用服务器。

这种方法，性能方面没有问题，虽然，还是2次http请求，但是不是每一次请求都需要域名解析，一次解析，ip就会记录到本地。下次，直接访问记录的ip。因此，性能无问题。

但是，由于域名解析服务器解析出的ip，如果出错，不会很快更新，且用户已经本地存储了ip也不会很快改变。因此，采用这种方案时，需要两级负载均衡。若应用服务器出错，在第二层负载均衡去掉。

对于安全性，现实使用时，该方法主要适用于两层负载均衡的情况，DNS负载均衡用于第一层负载均衡，解析出来的是第二层负载均衡服务器，因此，脆弱的服务器还是可以在内网中。淘宝、百度，不同时间ping，返回地址不同，意味着都是用了DNS负载均衡。

在应用层进行负载均衡，收到请求时，将请求转发到内网，再将收到的内网响应，返回给用户。

nagix本身的反向代理服务器，就有该功能。一般应用服务器是几十台，这种模式够用，再多一些，会不够用。因此，大一些的网站不会使用。

因为用的http请求协议，http比较重（比tcp的包重）。对反向代理服务器压力很大，其通过应用程序级别的线/进程才能完成分发，还要等应用服务器返回，因此，会有性能瓶颈。即使负载均衡做集群效率也低，因为后面的应用服务器有限。

因此，可以应用的规模很有限。

负载均衡服务器，和反向代理负载均衡原理相同，但是是在tcp层，修改包中源地址和目标地址，并发送到内网，收到响应后，再修改目标地址和原地址，返回给用户。

因为，负载均衡服务器处理的是ip那一层包，因此，处理能力可以提高。

但是，这种方法，请求和响应都通过了负载均衡，尤其是响应一般比较大。响应出口网络带宽会成为瓶颈。

数据链路层负载均衡，IP地址不变，只修改网卡MAC地址。应用服务器和负载均衡服务器共享一个虚拟ip。因为ip没有被修改过，tcp/ip协议还是通的，可以通过校验。又由于目的地址的mac地址改变了，因此，处理响应不用再经过负载均衡服务器。

大型互联网应用主要使用的负载均衡方案，也称为负载均衡的三角模式。

轮询

该方案已经被淘汰的。

通过session复制的方式，集群规模会受限制，复制不过来。做集群就是因为用户请求多，请求多，session也多，如果每个都有所有的session，对服务器压力很大。

来自相同的ip，总是到同一个应用服务器。这种方法也很快就淘汰了。

因为，会话需要会话关闭，如果因为发布程序，kill进程，session丢失。系统的可用性会下降。

发请求时，带cookie发送服务器，session记录的cookie中，返回给浏览器。任何一台服务器可以重cookie里得到session。

缺点：cookie变大，网络开销有影响。且有些浏览器禁用cookie，不好用。

早期使用的这个方案。缺点明显，但是生命力强。

对服务器架构要求很低。

你可以直接买一台负载均衡交换机啊，何必要浪费1台服务器呢。

2 应该是每台都会有一个IP地址 外网 访问连接到的那个IP地址 是你的负载均衡交换机的IP地址 他随机把你的访问请求分配到你的3台服务器上

3 无主从关系，负载均衡交换机它会没2秒左右向你的服务器发送一个健康检查，如果发现你的服务器出现问题，它会自动屏蔽你这台服务器

4 你问的重复问题。

所说的服务器是web服务器吗？还有那10000左右的预算包括web服务器的钱吗？

我说的这个实在linux上实现的。。。。

这个可以用lvs代替，它可以实现F5的功能，只是性能比F5差，但是性价比绝对超高。

LVS(Linux Virtual Server)

LVS是一个开源的软件，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。

LVS集群采用三层结构，其主要组成部分为：

– A、负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。

– B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

– C、共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

另外，可以再给调度器一个备机，来实现高可用。。。

这个东西只要把服务器提供好了，找人来搭，费用会比用F5实惠很多。

http://baikebaiducom/view/645050htmlwtp=tt

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

Nginx是一个免费的，开源的，高性能的服务器和反向代理服务器软件，同时它也可以为IMAP和POP3服务器代理，以其高性能，稳定性，丰富的功能，结构简单，低资源消耗的特性换来广大运维者所喜爱。

Nginx与传统的服务器不同，不依赖线程来处理请求。相反，它使用一个更可扩展事件驱动架构(异步)。这种结构资源消耗较小，但更重要的是，可以承受较大的请求负荷。即使你不希望处理成千上万的请求，你仍然可以受益于Nginx的高性能和小的内存占用，以及其丰富的功能。

Nginx的反向代理：

反向代理指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接到客户端，此时代理服务器对外就表现为一个服务器，而此种工作模式类似于LVS-NET模型。

反向代理也可以理解为web服务器加速，它是一种通过在繁忙的web服务器和外部网络之间增加的 一个高速web缓冲服务器，用来降低实际的web服务器的负载的一种技术。反向代理是针对web服务器提高加速功能，所有外部网络要访问服务器时的所有请求都要通过它，这样反向代理服务器负责接收客户端的请求，然后到源服务器上获取内容，把内容返回给用户，并把内容保存在本地，以便日后再收到同样的信息请求时，它会将本地缓存里的内容直接发给用户，已减少后端web服务器的压力，提高响应速度。因此Nginx还具有缓存功能。

反向代理的工作流程：

1）用户通过域名发出访问请求，该域名被解析为反向代理服务器的IP地址；

2）反向代理服务器接收用户的请求；

3）反向代理服务器在本地缓存查找是否存在当前用户所请求的内容，找到则直接把内容返回给用户；

4）如果本地没有用户请求的内容，反向代理服务器会以自己的身份去后端服务器请求同样的信息内容，并把信息内容发给用户，如果信息内容是可以被缓存的，则会将该内容缓存在代理服务器的本地缓存中。

反向代理的好处：

1）解决了网站服务器对外可见的问题，提高了网站服务器的安全性；

2）节约了有限的IP地址资源，后端服务器均可使用私有IP地址与代理服务器进行通信；

3）加速了网站的访问速度，减轻了真是web服务器的负荷。

(一)、调度算法

Nginx的upstream指令用于指定proxy_pass和fastcgi_pass所使用的后端服务器，即nginx的反向代理功能，因此可以将两者结合起来使用以达到负载均衡的目的，而Nginx也支持多种调度算法：

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，则会跳过该服务器分配至下一个监控的服务器。并且它无需记录当前所有连接的状态，所以它是一种无状态调度。

2、weight

指定在轮询的基础上加上权重，weight和访问比率成正比，即用于表明后端服务器的性能好坏，若后端服务器性能较好则可将大部分请求分配给它，已实现其力所能及。

例如：

我后端服务器17223136148配置：E55202 CPU，8G内存

后端服务器17223136148配置：Xeon(TM)280GHz 2，4G内存

我希望在有30个请求到达前端时，其中20个请求交给17223136148处理，剩余10个请求交给17223136149处理，就可做如下配置

upstream web_poll {

server 17223136148 weight=10;

server 17223136149 weight=5;

}

3、ip_hash

每个请求按访问ip的hash结果分配，当新的请求到达时，先将其客户端IP通过哈希算法进行哈希出一个值，在随后的请求客户端IP的哈希值只要相同，就会被分配至同一个后端服务器，该调度算法可以解决session的问题，但有时会导致分配不均即无法保证负载均衡。

例如：

upstream web_pool {

ip_hash;

server 17223136148:80;

server 17223136149:80;

}

4、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream web_pool {

server 17223136148;

server 17223136149;

fair;

}

5、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream web_pool {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

}

每个设备的状态设置为:

1down 表示当前的server不参与负载,用于ip_hash中

2weight 默认为1weight越大，负载的权重就越大。

3max_fails 允许请求失败的次数默认为1设为0则表示关闭该项功能，当超过最大次数时，返回proxy_next_upstream 模块定义的错误

4fail_timeout 在max_fails定义的失败次数后，暂停的时间。

5backup 可以将其理解为备机，其它所有的非backup机器down或者忙的时候，才会将请求分配给backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡，用来给不用的server来使用。

(二)、指令的使用

1、upstream

声明一组可以被proxy_pass和fastcgi_pass引用的服务器；这些服务器可以使用不同的端口，并且也可以使用Unix Socket；也可以为服务器指定不同的权重。如：

upstream web_pool {

server coolinuz9966org weight=5;

server 17223136148:8080 max_fails=3 fail_timeout=30s;

server unix:/tmp/backend3;

}

2、server

语法：server name [parameters]

其中的name可以是FQDN，主机地址，端口或unix套接字；如果FQDN解析的结果为多个地址，则每个地址都会被用到。

3、proxy_pass

语法：proxy_pass URL;

该指令用于指定代理服务器的地址和URL将被映射为的URL或地址和端口。即用来指定后端服务器的地址或URL[端口]。

4、proxy_set_header

语法：proxy_set_header header value;

该指令允许重新定义和添加一些将被转移到被代理服务器的请求头部信息。

例如：

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

注意：$proxy_add_x_forwarded_for包含客户端请求头中的"X-Forwarded-For"，与$remote_addr用逗号分开，如果没有"X-Forwarded-For" 请求头，则$proxy_add_x_forwarded_for等于$remote_addr

顺便补上Nginx的内置变量：

$args, 请求中的参数;

$is_args, 如果已经设置$args，则该变量的值为“？”，否则为“”。

$content_length, HTTP请求信息头里的"Content-Length";

$content_type, 请求信息头里的"Content-Type";

$document_root, 针对当前请求所属的root指令设置的根目录路径;

$document_uri, 与$uri相同;

$host, 请求信息中的"Host"，如果请求中没有Host行，则等于设置的服务器名;

$limit_rate, 对连接速率的限制;

$request_method, 请求的方法，比如"GET"、"POST"等;

$remote_addr, 客户端地址;

$remote_port, 客户端端口号;

$remote_user, 客户端用户名，认证用;

$request_filename, 当前请求的文件路径名

$request_body_file, 客户端请求主体的临时文件名。

$request_uri, 请求的URI，带参数;

$query_string, 与$args相同;

$scheme, 所用的协议，比如http或者是https，比如rewrite ^(+)$ $scheme://examplecom$1 redirect;

$server_protocol, 请求的协议版本，"HTTP/10"或"HTTP/11";

$server_addr, 服务器地址，如果没有用listen指明服务器地址，使用这个变量将发起一次系统调用以取得地址(造成资源浪费);

$server_name, 请求到达的服务器名;

$server_port, 请求到达的服务器端口号;

$uri, 请求的URI，可能和最初的值有不同，比如经过重定向之类的。

5、proxy_read_timeout

语法：proxy_read_timeout time;

这个指令设置Nginx与后端服务器建立连接后。等待后端服务器的响应时间

6、proxy_send_timeout

语法：roxy_send_timeout time;

该指令指定请求转移到后端服务器的超时时间。整个传输的要求时间不超过超时时间，但只有两次写操作之间。如果在此时间之后的后端服务器将不采取新的数据，然后nginx将关闭连接。

7、proxy_connect_timeout

语法：proxy_connect_timeout time;

该指令用来设置分配到后端服务器的连接超时时间。

8、proxy_buffers

语法: proxy_buffers the_number is_size;

该指令设置缓冲区的数目和大小，缺省情况下，一个缓冲区的大小和页面大小相同。

9、proxy_buffer_size

语法：proxy_buffer_size buffer_size;

代理缓冲区，该指令用于保存用用户的头部信息。

10、proxy_busy_buffers_size

语法：proxy_busy_buffers_size size;

用于当系统负载较大，缓冲区不够用时，可以申请更大的proxy_buffers

11、proxy_temp_file_write_size

语法：proxy_temp_file_write_size size;

用于指定缓存临时文件的大小

(三)、功能完善

安装配置第三方模块，实现upstream中对后端web server的健康状态检测：

模块下载地址：https://githubcom/cep21/healthcheck_nginx_upstreams；模块名称：ngx_http_healthcheck_module

安装配置方法：

1、首先解压healcheck模块到某路径下，这里假设为/tmp/healthcheck_nginx_upstreams

#tar -xvf cep21-healthcheck_nginx_upstreams-16d6ae7targz -C /tmp/healthcheck_nginx_upstreams

2、对nginx打补丁

首先解压nginx，并进入nginx源码目录：

# tar xf nginx-134targz

# cd nginx-1011

# patch -p1 < /tmp/healthcheck_nginx_upstreams/nginxpatch

而后编译nginx，在执行configure时添加类似下面的选项：

--add-module=/tmp/healthcheck_nginx_upstreams

所以，这里就使用如下命令：

# /configure \

--prefix=/usr/local/nginx \

--sbin-path=/usr/sbin/nginx \

--conf-path=/etc/nginx/nginxconf \

--lock-path=/var/lock/nginxlock \

--user=nginx \

--group=nginx \

--with-http_ssl_module \

--with-http_flv_module \

--with-http_stub_status_module \

--with-http_gzip_static_module \

--http-proxy-temp-path=/var/tmp/nginx/proxy/ \

--http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \

--with-pcre \

--add-module=/tmp/healthcheck_nginx_upstreams

# make && make install

ngx_http_healthcheck_module模块的使用方法：

1、此模块支持的指令有：

healthcheck_enabled

##启用此模块

healthcheck_delay

##对同一台后端服务器两次检测之间的时间间隔，单位毫秒，默认为1000；

healthcheck_timeout

##进行一次健康检测的超时时间，单位为毫秒，默认值2000；

healthcheck_failcount

##对一台后端服务器检测成功或失败多少次之后方才确定其为成功或失败，并实现启用或禁用此服务器；

healthcheck_send

##为了检测后端服务器的健康状态所发送的检测请求；如：healthcheck_send "GET /health HTTP/10" 'Host: coolinuz9966org';

healthcheck_expected

##期望从后端服务器收到的响应内容；如果未设置，则表示从后端服务器收到200状态码即为正确；

healthcheck_buffer

##健康状态检查所使用的buffer空间大小；

healthcheck_status

通过类似stub_status的方式输出检测信息，使用方法如下：

location /stat {

healthcheck_status;

}

(四)、配置与实现

配置代码如下：

http {

upstream web_pool {

server 17223136148:80 weight=10;

server 17223136149:80 weight=5;

healthcheck_enabled;

healthcheck_delay 1000;

healthcheck_timeout 1000;

healthcheck_failcount 2;

healthcheck_send "GET /health HTTP/10";

}

server {

listen 80;

location / {

proxy_set_header Host $http_host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://web_pool;

proxy_connect_timeout 3;

}

location /stat {

healthcheck_status;

}

}

}

在这里设置“proxy_set_header”参数，是因为Nginx在做反向代理的时候，要代替客户端去访问服务器，所以，当请求包经过反向代理后，在代理服务器这里这个IP数据包的IP包头做了修改，最终后端web服务器得到的数据包的头部的源IP地址是代理服务器的IP地址，这样一来，后端服务器的程序给予IP的统计功能就没有任何意义,或者后端web服务器上有多个基于域名的虚拟主机时，就要通过添加Header头信息Host，用于指定请求的域名，这样后端web服务器才能识别该反向代理访问请求由哪个虚拟主机来处理。

(五)、小结

通过以上我们可以看出Nginx的配置其实是比较其他的web服务器软件是比较简单的，但是其实现的功能确实相当强大丰富的。通过Nginx的反向代理已经支持灵活的正则表达式匹配，可以实现网站的动、静分离，让动态的php等程序网页去访问php web服务器，让缓存页、、javascript、css、flash去访问Squid等缓存服务器或文件服务器。加之Nginx对静态内容的高性能，高并发量，Nginx作为前端代理负载均衡成为越来越多架构师的首先方案。

双机热备：

只有一个主机在工作，不能够平均分担负载，同一时间只有一台机器在工作，如果工作的机器发生故障，则通过集群将所有服务转移给另外一台机器，转移时间30秒到2分钟不等，根据数据量决定。

大多数应用于对安全性要求较高，且无24小时人员值守的环境。

负载均衡：

2台或2台以上的机器同时运行，设备之间没有主次之分，需要负载均衡设备，需要数据同步软件，并且基本上只应用前端接收请求的设备。当单台设备出现故障，则由其他设备平均分担所有应用请求。

大多数应用于访问量非常大的场合。只要有一台设备在工作，访问就不会中断。

双机热备与负载均衡区别在于：

1、双机热备相当于2台服务器其中有一台是另一台的备机，也可以互为备机；主机在运行服务时，备机处于检测状态，主机发生故障后，备机将接管主机的服务

2、负载均衡是在这2台服务器（或N多台）之上增加了一台负载均衡服务器，负载均衡服务器的作用是把用户的请求平均分配到每个节点；增加集群整体的处理能力；实现网络访问的均衡

3、双机热备是为保障247小时高可用不停机而推出的产品，而负载均衡是解决服务器压力过大，网络请求大量并发而设计的产品

4、双机热备的优点是：能保障用户服务不间断；负载均衡的优点：WEB访问流畅，用户请求平均分布在每个节点上

5、双机热备缺点：用传统加加阵列的方式增加了存储空间，同样也形成了单点故障；有可能双机热备成为虚设，因为一旦阵列崩溃，服务也意味这停止。 （在条件允许的情况下，可以考虑不加阵列，用软件方式做数据同步，阵列做为备份数据的存储，不失为一个好办法）

6、负载均衡的缺点：适用静态WEB，如果是数据库将不起作用，数据库的多向同步目前还没有完全解决的方案（比如某用户被分配到1号服务器，他在数据库里添加了一条信息；当他下次访问，却被分到2号服务器，那么他原先的数据库信息将不存在）

对于动态的、时常更新的WEB，多向的数据同步也很难，不过我现在已经有了不错的解决办法 因为增加了负载均衡服务器，使得各个节点冗余；但负载均衡器又会形成新的单点故障，所以如果要增加负载均衡设备，一定要选2台做均衡器冗余。