负载均衡基本介绍

负载均衡架构部分转自 58沈剑 [架构师之路]( https://mpweixinqqcom/s

负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据均匀分摊到多个操作单元上执行，负载均衡的关键在于均匀

常见的负载均衡方案：

客户端层到反向代理层的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

反向代理层到站点层的负载均衡，是通过“nginx”实现的。通过修改nginxconf，可以实现多种负载均衡策略：

站点层到服务层的负载均衡，是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。

数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。

请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。

（1）按照range水平切分

（2）按照id哈希水平切分

[上传中(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：

（1）价格实在非常昂贵

（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

nginx和F5： https://blogcsdnnet/chabale/article/details/8956717

nginx和lvs比较： https://blog51ctocom/hzcto/2086691

lvs： https://wwwcnblogscom/liwei0526vip/p/6370103html

ELB： https://awsamazoncom/cn/elasticloadbalancing/

SLB： https://helpaliyuncom/product/27537html

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？

（1）评估流量

1000万DAU，换算成秒级（一天12小时），平均约等于232。

考虑每个用户操作次数，假定10，换算成平均QPS=2320。

考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。

考虑静态资源、资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。

（2）容量规划

考虑高可用、异地多活，QPS 2=232000。

考虑未来半年增长，QPS15=348000。

（3）方案设计

可以用三级导流：

第一级，DNS，确定机房，以目前量级，可以不考虑。

第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。

第三级，Nginx+KeepAlived，确定实例。

（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

999999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

后端的service有可能部署在硬件条件不同的服务器上：

1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；

2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

（1）通过“静态权重”标识service的处理能力

优点： 简单，能够快速的实现异构服务器的负载均衡。

缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

（2）通过“动态权重”标识service的处理能力

提问：通过什么来标识一个service的处理能力呢？

回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护

案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的

2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整

3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动

4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法

5）动态权重法，还可以用做service的过载保护

在本教程中，我们将教你如何使用HAProxy为你的WordPress服务器搭建第四层负载均衡--特别是web应用层。负载均衡web服务器要在设置中增加冗余，这会在碰到服务器失败、网络问题时增加服务的可靠性；同时将负载分摊在多个服务器上可以提交读操作的性能。我们假设你所配置中包括一个WordPress应用服务器去连接一台单独的MySQL数据库服务器（假设你已经知道如何架设）。

如果你只是运行了一个单独的web服务器应用程序，那么第四层负载均衡就比较适用。如果你的环境更复杂（例如你想通过一个单一的入口在不同的服务器上运行WordPress和一个静态web服务器），那么就可能就需要关注应用层（第七层）负载均衡。

本文是以WordPress为例子，但是它的一般概念可以用于负载平衡,无状态的web应用。

预备知识

在继续本教程之前，你需要首先要完成架设一个拥有单独数据库服务器的WordPress站点的教程（或者使用类似的步骤）：如何使用MYSQL建立一个远程数据库来优化站点性能。

当你跟着教程在单独Web应用和数据库服务器下搭建完WordPress后，你应该有两个VPS。因为我们要处理几个VPS,为了参考，我们就成这两个VPS为：

wordpress-1:你的WrodPress web应用服务器

mysql-1：你的Mysql服务器

现在你的环境的抽象视角看起来像下图这个样子：

除了你当前的环境外，我们在本教程中还需要有两个额外的VPS。我们称他们为：

wordpress-2:第二个WordPress web应用服务器

haproxy-www:HAProxy服务器，做负载均衡用

如果你对负载均衡的基本概念或者数据还不熟悉，比如四层负载均衡或者后端或者ACL，这里有篇文章解释这些基本概念：HAProxy及负载均衡概念介绍（译注：大家可百度查找）。

我们的目标

最终，我们想拥有以下一个环境：

也就是说，你的用户将通过HAProxy服务器到达WordPress站点，其中HAProxy服务器会议轮循的方式将用户请求负载均衡至WrodPress应用服务器。你的两个WordPress应用服务器（或者更过，如果你愿意）将都会请求MYSQL数据库。

当前环境快照

可选：在继续本教程之前，你可能想为你当前环境创建快照。本教程中快照有两个目的：

如果发生错误可以回滚到可工作环境

对原始服务器做一次性复制，而不需要再次安装和配置PHP以及Nginx

注意：为环境创建快照需要短暂的关闭VPS

为wordpress-1和mysql-1两个VPS做一个快照。

现在有了快照以后，我们就可以准备好继续搭建环境中其他部分了。

创建第二台web应用服务器

现在我们需要创建第二个VPS来分担原始应用服务器的负载。有两种选择：

从之前的快照wordpress-1中创建一个新的VPS

从头开始重新创建一个VPS并且设置该VPS和wordpress-1有相同的软件和配置

不论那种方法，如果网络可用，一定要确保勾选个人网络。个人网络是本教程中所有VPS都需要的。

如果没有个人网络选项，用你的VPS的公开IP来替代内网IP。需要注意的是，当使用公网IP在应用服务器和数据库服务器之间传输敏感数据比如非加密的数据库密码，并不是一个很好的选择，因为这些信息需要在互联网上传输。

方式一：使用快照创建新的VPS

创建一个新的VPS，叫做wordpress-2,使用你为wordpress-1做的快照来做。

如果你选择的这种方式，可以跳过“方式二”直接去看“同步web应用文件”小节。

方式二：从头创建一个新的VPS

这种方式和“方式一”可二选一。

如果你想从头设置wordpress-2服务器，而不是使用wordpress-1的快照，那么你要确保安装的软件相同。如果你忘了如何安装和设置原始wordpress服务器，可以参考预备知识章节中如何设置web服务器小节。

快速参考,这里是一个相关软件和配置文件的列表,需要你来安装或复制：

软件方面：

Mysql客户端

Nginx

PHP

安装完这些软件后，在你的wordpress-2服务器上运行一下命令：

sudo apt-get update

sudo apt-get install mysql-client

sudo apt-get install nginx php5-fpm php5-mysql

原始应用服务器上需要创建或编辑的配置文件：

/etc/php5/fpm/phpini

/etc/php5/fpm/poold/wwwconf

/etc/nginx/sites-available/examplecom

/etc/nginx/sites-enabled/examplecom

当你修改完配置文件后，不要忘了冲洗PHP和Nginx，可以使用一下命令：

sudo service php5-fpm restart

sudo service nginx restart

在新服务器的安装和配置完成以后，我们需要同步wordpress应用文件。

同步Web应用文件

在应用程序可以进行负载均衡之前，我们需要确保新应用服务器的应用程序文件和原始wordpress服务器的文件是同步的。这些文件的位置也就是你安装wordpress的位置，以及其他的一些文件。除了wordpress运行所需要的配置文件之外，上传的文件和通过wordpress接口安装的插件的安装文件和这些插件上传的文件都需要去同步。在预备知识文章中，我们将wordpress安装在/var/www/examplecom路径下--我们将

在所有的例子中都会使用这个路径，但是你需要将这个路径替换为你wordpress的实际安装路径。

有很多方法在服务器之间同步文件--NFS或者glusterFS都是不错的选择。我们将使用glusterFS来满足我们所有的同步需求，因为它允许每个应用服务器来存储应用程序文件的副本，同时也会保持文件系统的一致性。下图是我们共享存储方案的概念图：

如果你对本小节中使用的glusterFS完全不熟悉，请参考这个GlusterFS教程（https://wwwdigitaloceancom/community/tutorials/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers），这是本小节的基础。

注意：下面的内容将经常在wordpress-1和wordpress-2服务器之间跳转，请确保在正确服务器上运行响应命令，否则你将遇到麻烦。

编辑hosts文件

如果你有一个内部DNS，而且这个DNS记录了你VPS的内部IP地址，那么你可以跳过这一步直接配置并执行glusterFS相关命令。

否则，需要在wordpress-1和wordpress-2上编辑/etc/hosts文件：

sudo vi /etc/hosts

增加以下两行，将红色字替换为你应用服务器的各自ip：

wordpress_1_private_IP wordpress-1

wordpress_2_private_IP wordpress-2

保存并退出。

安装GlusterFS并配置一个冗余盘

在wordpress-1和wordpress-2上使用apt-get命令安装glusterFS服务端软件：

sudo apt-get install glusterfs-server

在wordpress-1上，运行以下命令来和wordpress-2保持对等：

sudo gluster peer probe wordpress-2

在wordpress-2上，运行以下命令来和wordpress-1保持对等：

sudo gluster peer probe wordpress-1

在wordpress-1和wordpress-2上，创建路径用来存储glusterFS所管理的文件，运行：

sudo mkdir /gluster-storage

在wordpress-1上，创建glusterFS副本，我们称作volume1,glusterFS 会将它存放在/gluster-storage中的数据保存在你所有的应用服务器上，运行：

sudo gluster volume create volume1 replica 2 transport tcp wordpress-1:/gluster-storage wordpress-2:/gluster-storage force

预期输出以下结果：

volume create: volume1: success: please start the volume to access data

再次在wordpress-1上，运行一下命令来启动刚刚创建的glusterFS卷，在volume1上运行：

sudo gluster volume start volume1

预期输出以下结果：

volume start: volume1: success

在wordpress-1上，如果你想查看刚创建和启动的glusterFS卷的信息，运行：

sudo gluster volume info

你需要明白的是目前有两个glusterFS“同盟”，每个对应一个wordpress服务器。

现在我们已经运行了一个glusterFS盘，为了能够使用它来同步文件，我们需要将该盘挂载。

挂载共享存储

首先挂载wordpress-1上的文件系统。

在wordpress-1上，修改fstab文件来使共享文件系统可以随机启动：

sudo vi /etc/fstab

添加以下行到fstab来将/storage-pool目录作为挂载点：

wordpress-1:/volume1/storage-pool glusterfs defaults,_netdev 0 0

保存并退出。

在wordpress-1上，现在将glusterFS盘挂载至/storage_pool文件系统：

sudo mkdir /storage-pool

sudo mount /storage-pool

在wordpress-1上挂载共享盘/storage-pool后，你可以运行df -h命令来列出当前已挂载的文件。接下来，我们将使用类似的流程来挂载wordpress-2上的共享文件系统。

在wordpress-2上，编辑fstab来使共享系统随机启动：

sudo vi /etc/fstab

添加以下行到fstab来将/storage-pool目录作为挂载点：

wordpress-2:/volume1 /storage-pool glusterfs defaults,_netdev 0 0

在wordpress-2上，现在将glusterFS盘挂载至/storage_pool文件系统：

sudo mkdir /storage-pool

sudo mount /storage-pool

现在，所有在/storage-pool文件系统中创建、修改或删除的文件都会在两个wordpress服务器之间同步，即使当其中一个服务器暂时故障时也会同步。

将wordpress文件移至共享存储

下一步是将wordpress-1的wordpress文件移动到共享存储中。请将红色字体替换为你自己的值。/var/www/examplecom表示wordpress文件的位置(nginx也会在这里查找文件)，examplecom本身只是根目录。

在wordpress-1上，运行以下命令来移动wordpress文件至共享文件系统/storage-pool:

sudo mv /var/www/examplecom /storage-pool/

sudo chown www-data:www-data /storage-pool/examplecom

接下来，你可能想创建一个符号链接来指向wordpress在共享文件中位置：

sudo ln -s /storage-pool/examplecom /var/www/examplecom

目前wordpress文件放在共享文件系统/storage-pool中，这些文件接受Nginx访问他们的原始路径/var/www/examplecom。

将新的应用服务器指向共享存储区

下一步是我们在新web应用程序服务器上创建一个符号链接指向WordPress文件共享文件系统。

如果你选择使用快照创建wordpress-2，在wordpress-2上运行以下命令：

sudo rm /var/www/examplecom

sudo ln -s /storage-pool/examplecom /var/www/examplecom

如果你从头创建wordpress-2服务器，在wordpress-2上运行以下命令：

sudo mkdir -p /var/www

sudo ln -s /storage-pool/examplecom /var/www/examplecom

这就是wordpress应用的文件同步。接下来是使新服务器wordpress-2连接数据库。

创建一个新的数据库用户

由于Mysql使用用户名和源主机来区别用户，我们需要创建一个新的wordpress用户来连接新的服务器wordpress-2。

在数据库服务器（mysql-1）上连接至MYSQL控制台：

mysql -u root -p

在一下mysql语句中，将红色字体替换为你真实环境的参数：

wordpress用户：Mysql中wordpress用户。确保和已经存在的用户名保持一致。

wordpress2private_IP：wordpress-2服务器的内部ip。

密码：wordpress用户的Mysql数据库密码。去报和已经存在的用户名密码保持一致。

在wordpress-2上mysql控制台中运行以下命令：

CREATE USER 'wordpressuser'@'wordpress_2_private_IP' IDENTIFIED BY 'password';

GRANT SELECT,DELETE,INSERT,UPDATE ONwordpress TO 'wordpressuser'@'wordpress_2_private_IP';

FLUSH PRIVILEGES;

现在第二台服务器wordpress-2就可以登录mysql服务器mysql-1了。

还没负载均衡

注意，有两个应用服务器在运行但是他们并没有被负载均衡，因为每个服务器必须通过他们的外网IP来访问。而我们希望能够通过相同的URL访问该应用程序，如http://examplecom/，以及在两台服务器之间做流量分配。

安装HAProxy

在内网中创建一个新的VPS，在本教程中，我们叫做haproxy-www。

在haproxy-www服务器上使用apt-get命令来安装HAProxy:

sudo apt-get update

sudo apt-get install haproxy

我们需要使用HAProxy初始化脚本来启动和停止HAProxy：

sudo vi /etc/default/haproxy

将ENABLED值改为1来开启初始化脚本：

ENABLED=1

保存并退出。

现在HAProxy可以在服务器上被启动和停止。当然，你现在可以使用命令来控制HAProxy了。让我们来检查下它是否运行：

/etc/initd$ sudo service haproxy status

输出结果：

haproxy not running

HAProxy没有运行。这是对的，因为它首先需要配置。接下来，让我们来配置HAProxy。

HAProxy配置

HAProxy的配置文件主要分为以下两部分：

Global:设置进程级参数

Proxies:包括默认、监听、前端、后端参数

Global配置

所有的HAProxy配置都需要在HAProxy服务器haproxy-www上进行。

首先，复制一份默认的haproxycfg文件：

cd /etc/haproxy; sudo cp haproxycfg haproxycfgorig

现在，使用文本编辑器打开haproxycfg文件：

sudo vi /etc/haproxy/haproxycfg

你将看到有两部分已经被定义：global和defaults。首先,我们将对一些默认参数做一些修改。

在默认情况下，找到一下两行：

mode http

option httplog

将其中http替换为tcp,结果如下：

mode tcp

option tcplog

选择tcp作为HAProxy执行第4层负载平衡模式配置。在我们的例子中,这意味着一个特定的IP地址和端口中所有传入的流量将被转发到同一后端。如果你不熟悉这一概念,请阅读在HAProxy介绍中的负载均衡小节。

先不要关闭配置文件，我们将加上proxy配置。

代理配置（Proxyies）

我们首先要做的事情是增加前端。对一个基本的4层负载均衡设置，前端监听一个特定的IP地址和端口的流量，并将传入流量转发到一个指定的后端。

在配置文件的末尾，让我们添加上我们的前端：www。请将haproxy_www_public_IP替换为你自己的haproxy-www服务器IP地址：

frontend www

bind haproxy_www_public_IP:80

default_backend wordpress-backend

以下是对上面的前端配置代码片段中的每一行是什么意思做出解释：

frontend www：指定了一个名为“www”的前端,我们将用它来处理传入www的流量

bind haproxywwwpublic_IP:80：将haproxywwwpublic_IP替换为你haproxy-www服务器的外网ip。这是告诉haproxy这个前端将处理这个ip和端口上的流量。

default_backend wordpress-backend：这指定所有这些前端的流量将会转发到wordpress-backend,这在下一步我们将定义

配置完前端后，继续将以下后端配置加入文件末尾：

backend wordpress-backend

balance roundrobin

mode tcp

server wordpress-1 wordpress_1_private_IP:80 check

server wordpress-2 wordpress_2_private_IP:80 check

以下是对上面每行配置的解释：

backend wordpress-backend：指定了一个名为“wordpress-backend”的后端

balance roundrobin：指定该后端将使用“轮循”的负载均衡算法

server wordpress-1 ：指定了一个名为“wordpress-1”的后端服务器,内外nagIP(你必须替换为你自己服务器ip)和端口监听,在这个例子中为80端口。“check”选项表示使负载均衡器对这个服务器定期进行健康检查

server wordpress-2 ：指定了一个名为“wordpress-2”的后端

保存并退出。

现在HAProxy可以启动了，但是让我们先开启日志功能。

开始HAProxy日志功能

启用HAproxy日志功能非常简单，首先编辑rsyslogconf文件：

sudo vi /etc/rsyslogconf

接着找到一下两行，取消这两行注释来开启UDP日志功能：

$ModLoad imudp

$UDPServerRun 514

$UDPServerAddress 127001

现在重启rsyslog来使新配置生效：

sudo service rsyslog restart

HAProxy日志功能现在已经开启了！日志文件将在HAProxy启动后被放在/var/log/haproxylog。

启动HAProxy和PHP/Nginx

在haproxy-www服务器上，启动HAProxy来使配置生效：

sudo service haproxy restart

取决于你如何设置您的新应用程序服务器,您可能需要重新启动你的WordPress应用程序通过重启PHP和Nginx。

在wordpress-2服务器上，重启PHP和Nginx：

sudo service php5-fpm restart

sudo service nginx restart

现在WordPress应该运行在两个应用程序服务器,它们是负载均衡的。但仍有最后一个配置需要更改。

更新WordPress配置

现在你的WordPress应用程序的URL已经改变,我们必须在WordPress更新几个设置。

在wordpress服务器,编辑你的wp-configphp文件。它位于WordPress的安装位置(在本教程中,它是安装在/var/www/examplecom但你安装可能会有所不同)：

cd /var/www/examplecom; sudo vi wp-configphp

找到"DB_NAME"所在行；增加以下配置在该行之上，并且替换红色的值：

define('WP_SITEURL', 'http://haproxy_www_public_IP');

define('WP_HOME', 'http://haproxy_www_public_IP');

保存并退出。

现在WordPress url配置为指向您的负载平衡器,而不是只有最初的WordPress服务器,而且在当你试着访问wp-admin控制台时发挥作用。

负载均衡完成

您的web应用程序服务器现在是负载均衡的。你的负载平衡WordPress现在可以访问您的用户通过负载均衡器haproxy-www的外网IP地址或域名访问!

总结

现在您的用户将在两个wordpress服务器之间负载。另外，如果其中一个wordpress挂了，那么您的站点仍然是可用的，因为另一个wordpress服务器仍然在处理流量。

使用此设置,记住你的HAProxy负载均衡服务器haproxy-www以及数据库服务器mysql-1,需要为你的网站运行正常而工作。

1本文由程序员学架构摘译

2 本文译自https://wwwdigitaloceancom/community/tutorials/how-to-use-haproxy-as-a-layer-4-load-balancer-for-wordpress-application-servers-on-ubuntu-14-04

众所周知，windows server 2012是支持虚拟系统的。那么具体怎么对服务器设置网络负载均衡，一起来看看。

1、给2台WEB服务器装置NLB，以后在其间恣意一台上来新建群集，然后将别的一台加入到这个群会集即可，并保证这2台服务器都是运用的静态IP。

2、在web-01(1921681130)上从管理工具中翻开 网络负载均衡器，右击“网络负载平衡群集”，挑选“新建群集”

3、在“新群集：衔接”窗口中将 1921681130增加为主机，点击下一步进入 “新群集：主机参数”，下一步，进入 “新群集：群集IP地址”，增加窗口中的“增加” 将1921681254 增加到窗口中然后下一步；

4、进入 “新群集：群集参数”，挑选“多播”然后下一步；进入 “新群集：端口规则”，选中悉数，然后修改；将端口范围改成 80~80，协议选 “TCP”，相关性选“无”点击断定回到主窗口，然后点击完结。

5、经过上面的过程，咱们现已建立了一个群集，并且将web-01加入到了群会集，咱们还需要手动将web-02也加入到群会集。在群集(1921681254)上右键点击“增加主机到群集”。衔接”窗口中的 主机中输入1921681131即可。

　　根据一些专家的调查分析，发现企业在使用数据库的时候，90%以上主要用来查询。有些企业这个比例甚至更高。也就说，用户对数据库的操作，其实更新操作占的比例很少。大部分的操走都只是查询操作。

　　如一些论坛，大部分用户只会看贴，而不会发帖。这就是一个典型的查询操作比例大大超过更新操作比例的例子。针对这种情况，其查询操作往往是其数据库性能的瓶颈。如何有效提高查询的性能，这就使各个数据库专家在考虑的问题。在SQL Server数据库中，已经有了一个现成的解决方案。数据库管理员可以利用缓存服务器来提高数据库的性能。笔者这里就以SQLServer2008为例，谈谈如何利用缓存服务器来实现负载均衡，来提高数据库的查询效率。

　　一、 数据查询与数据更新分开走。

　　如上图所示，如果用户要查看某个帖子，其就会打开某个连接。此时WEB应用服务器就会从后台数据库中查询相关的记录。这里需要注意的是，由于其只是查看帖子，而不涉及到更新的操作，为此WEB应用服务器就只从缓存服务器中读取数据。这个缓存服务器中的记录跟数据库服务器的内容是同步的。WEB应用服务器在从数据库缓存服务器读取数据之前，还会先判断一下哪台数据库服务器比较空。会优先连接到比较空闲的数据缓存服务器中，然后从这台服务器中读取数据。所以，当访问这个论坛的用户比较多时，这个数据缓存服务器能够实现负载均衡的需要。

　　如果用户看了某个帖子，现在需要发表一个评论，此时后台数据库会怎么操作呢注意，当WEB应用服务器发送了一个 Update更新操作的时候，其应用服务器会自动连接到数据库服务器，而不会再连接到数据库缓存服务器。而是直接向数据库服务器发送更新操走的语句。当数据库服务器更新了相关的内容之后，会与数据库缓存服务器实现数据的同步。从上图中可以看出，整个数据查询与数据更新WEB应用服务器是分两条路走。其实这就好像是公路上分道行驶，机动车走机动车道;非机动车走非机动车道。

　　　　如此的话，就不会因为非机动车比较慢，而影响到机动车的速度。在这个方案中，将数据库的更新操作与查询操作分开来走，也是类似的道理。在查询时，数据流是单向流动的，所以能够在很大程度上提高查询的效率。从而让数据负载均衡的效果更加明显。总之，当某个应用程序查询操作大大超过更新操作时，通过在多个数据库间缓存只读数据，并在数据库间均匀连接客户端以分发负载，则就可以向外扩展工作负荷的读取分区，即实现负载均衡的目的。

　　二、 采用这个方案需要注意的地方。

　　在部署这个解决方案时，仍然有些数据库管理员需要关注的内容。如以下这些内容，数据库管理员需要根据企业的实际情况来进行调整，以提高这个方案的价值。

　　首先需要考虑数据缓存服务器与数据库服务器之间同步的频率问题。这个同步操作是一把双刃剑。若同步的频率太高，会影响数据库服务器与缓存服务器的性能;若同步频率比较低的话，则数据库缓存服务器中的数据得不到及时的更新。

　　如此的话，用户查询时可能在短时间内无法获取最新的数据。所以，一般来说，系统滞后的时间应该尽量的短，即数据库服务器的更新内容必须尽快与数据库缓存服务器进行同步。

　　理想的状态时，在更新数据库服务器的同时更新数据库缓存服务器。但是，这么做是以牺牲数据库与数据库缓存服务器的性能为代价的。为此数据库管理员在实施这个解决方案时，往往不会这么做。而是设置在一段时间之后同步。如可以设置为10秒、60秒、300秒或者更长的时间后进行同步。

　　具体这个同步的时间间隔多少为好，没有一个统一的标准。这需要数据库管理员根据企业对数据同步的要求不同而定。一般来说，数据库管理员在满足用户需要的前期下，可以将这个时间设置的相对长一点。这可以避免因为过多的同步操作而降低了这个方案的价值。其实，对于大部分用户来说，60秒左右的时间差异还是可以接受的。如在论坛中，一个人发帖后，在一分钟之后看到一般不会有什么问题。对于人的感觉来说，这个一分钟时间不长。但是对于数据库服务器来说，这一分钟可以做很多事情。所以，适当延长这个同步时间，却可以在很大程度上提高数据库服务器性能。这个时间的代价，有时候还是值得的。

　　其次，在数据库服务器与数据库缓存服务器之间，应该建立比较直接的、快速的网络连接。当用户比较多时，数据库服务器与数据库缓存服务器之间若发生同步操作，则会造成很多的网络流量。有时候同步操作发生时，影响这个工作的效率可能并不是数据库服务器或者数据库缓存服务器本身，而是他们之间的网络连接。

　　由于其可用的带宽跟不少数据库服务器系统的吞吐量，从而影响到了同步操作的效率。为此，在数据库服务器与数据库缓存服务器之间的网路连接，应该尽量的直接。如最好不要在中间夹着其他的不必要的网络设备;也最好不要在他们之间配备防火墙等安全策略。这些安全策略与网络设备都会在很大程度上影响到这个同步操作的效率。

　　另外，最好也不要有其他的应用服务来争抢带宽。所以简单的说，如果可能的话，在数据库服务器上部署多张网卡，直接与数据库源服务器实现双机互联，而那传输同步操作需要的数据，这是一个很不错的手段。由于其数据传输更直接、而且其他设备或者应用服务也会来争夺其带宽，同时又可以克服他们的非法攻击。为此，只要他们之间多距离比较短的话，采用这种方案可能效果会比较好，可以在最大程度内缩短这个同步操作所需要的时间，从而让其他用户尽早看到更新的数据。

　　第三为同步选择合适的复制方案。

　　那么该如何实现数据库服务器与缓存服务器之间的同步呢在SQLServer数据库中，有三个方案可供数据库管理员选择。这三个方案分别为快照复制、合并复制与事务复制。这三个复制模型各有各的特点。不过从最终效果来看，其都可以实现数据库服务器与数据库缓存服务器之间的同步。不过由于其内部的实现机制不同，为此其虽然结果相同，但是从性能等方面考虑，还是有差异的。

　　各种复制模型的原理与特点属于基本知识的范畴，笔者在这里就不做过多阐述了。笔者认为，在利用这个数据库缓存服务器来实现负载均衡的方案中，最好采用事务复制的同步方案。因为相比其他方案来说，事务日志能够满足事务的一致性、数据库服务器系统比较大的吞吐量、同步时尽量少的开销、以及系统比较短的滞后时间等等需求。

　　另外在有些企业中采用这个方案的话，还要考虑到表与记录的过滤需求。而通过事务复制的话，就可以实现对列和行的过滤。而其他复制模型的话，只能够部分满足这些需求。

　　　　所以，笔者认为，在选择数据同步方案时，可能选择事务复制来实现同步，更加的合适。不过最终是否真是如此，还是要求数据库管理员根据企业的实际需要，然后分别采用几个复制模型来进行测试，才能够得出真正合理的结果。

　　转载，仅供参考。

负载均衡

先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。

测试环境

由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。

测试域名 ：acom

A服务器IP ：1921685149 （主）

B服务器IP ：192168527

C服务器IP ：1921685126

部署思路

A服务器做为主服务器，域名直接解析到A服务器（1921685149）上，由A服务器负载均衡到B服务器（192168527）与C服务器（1921685126）上。

域名解析

由于不是真实环境，域名就随便使用一个acom用作测试，所以acom的解析只能在hosts文件设置。

打开：C:WindowsSystem32driversetchosts

在末尾添加

1921685149 acom

保存退出，然后启动命令模式ping下看看是否已设置成功

从截图上看已成功将acom解析到1921685149IP

A服务器nginxconf设置

打开nginxconf，文件位置在nginx安装目录的conf目录下。

在http段加入以下代码

upstream acom {

server 1921685126:80;

server 192168527:80;

}

server{

listen 80;

server_name acom;

location / {

proxy_pass http://acom;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

保存重启nginx

B、C服务器nginxconf设置

打开nginxconfi，在http段加入以下代码

server{

listen 80;

server_name acom;

index indexhtml;

root /data0/htdocs/www;

}

保存重启nginx

测试

当访问acom的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的indexhtml文件，以作区分。

打开浏览器访问acom结果，刷新会发现所有的请求均分别被主服务器（1921685149）分配到B服务器（192168527）与C服务器（1921685126）上，实现了负载均衡效果。

B服务器处理页面

C服务器处理页面

假如其中一台服务器宕机会怎样？

当某台服务器宕机了，是否会影响访问呢？

我们先来看看实例，根据以上例子，假设C服务器1921685126这台机子宕机了（由于无法模拟宕机，所以我就把C服务器关机）然后再来访问看看。

访问结果：

我们发现，虽然C服务器（1921685126）宕机了，但不影响网站访问。这样，就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。

如果bcom也要设置负载均衡怎么办？

很简单，跟acom设置一样。如下：

假设bcom的主服务器IP是1921685149，负载均衡到1921685150和1921685151机器上

现将域名bcom解析到1921685149IP上。

在主服务器(1921685149)的nginxconf加入以下代码：

upstream bcom {

server 1921685150:80;

server 1921685151:80;

}

server{

listen 80;

server_name bcom;

location / {

proxy_pass http://bcom;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

保存重启nginx

在1921685150与1921685151机器上设置nginx，打开nginxconf在末尾添加以下代码：

server{

listen 80;

server_name bcom;

index indexhtml;

root /data0/htdocs/www;

}

保存重启nginx

完成以后步骤后即可实现bcom的负载均衡配置。

主服务器不能提供服务吗？

以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。

如以上案例三台服务器：

A服务器IP ：1921685149 （主）

B服务器IP ：192168527

C服务器IP ：1921685126

我们把域名解析到A服务器，然后由A服务器转发到B服务器与C服务器，那么A服务器只做一个转发功能，现在我们让A服务器也提供站点服务。

我们先来分析一下，如果添加主服务器到upstream中，那么可能会有以下两种情况发生：

1、主服务器转发到了其它IP上，其它IP服务器正常处理；

2、主服务器转发到了自己IP上，然后又进到主服务器分配IP那里，假如一直分配到本机，则会造成一个死循环。

怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理acom的访问请求，得用一个新的。于是我们把主服务器的nginxconf加入以下一段代码：

server{

listen 8080;

server_name acom;

index indexhtml;

root /data0/htdocs/www;

}

重启nginx，在浏览器输入acom:8080试试看能不能访问。结果可以正常访问

既然能正常访问，那么我们就可以把主服务器添加到upstream中，但是端口要改一下，如下代码：

upstream acom {

server 1921685126:80;

server 192168527:80;

server 127001:8080;

}

由于这里可以添加主服务器IP1921685149或者127001均可以，都表示访问自己。

重启Nginx，然后再来访问acom看看会不会分配到主服务器上。

您好，很高兴为您解答。

1、企业实现Web服务器负载均衡

　　为了将负载均匀的分配给内部的多个服务器上，就需要应用一定的负载均衡策略。通过服务器负载均衡设备实现各服务器群的流量动态负载均衡，并互为冗余备份。并要求新系统应有一定的扩展性，如数据访问量继续增大，可再添加新的服务器加入负载均衡系统。

　　对于WEB服务应用，同时有几台机器提供服务，每台机器的状态可以设为regular(正常工作)或backup(备份状态)，或者同时设定为regular状态。负载均衡设备根据管理员事先设定的负载算法和当前网络的实际的动态的负载情况决定下一个用户的请求将被重定向到的服务器。而这一切对于用户来说是完全透明的，用户完成了对WEB服务的请求，并不用关心具体是哪台服务器完成的。

　　2、使用网络地址转换实现多服务器负载均衡

　　支持负载均衡的地址转换网关中可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。然而硬件实现的负载控制器灵活性不强，不能支持更优化的负载均衡策略和更复杂的应用协议。

　　基于网络地址转换的负载均衡器可以有效的解决服务器端的CPU和磁盘I/O负载，然而负载均衡器本身的性能受网络I/O的限制，在一定硬件条件下具有一定的带宽限制，但可以通过改善算法和提高运行负载均衡程序的硬件性能，来提高这个带宽限制。不同的服务类型对不同的服务器资源进行占用，我们使用的负载衡量策略是使用同一个负载进行评估，这对于大多数条件是适合的，然而最好的办法是针对不同的资源，如CPU、磁盘I/O或网络I/O等，分别监视服务器负载，由中心控制器选择最合适的服务器分发客户请求。

　　3、使用DNS服务器实现负载均衡

　　访问企业网服务器的用户急剧增加，一台服务器难以满足用户的访问需要，那么如何才能保证用户的正常访问呢解决方法有很多，如使用Windows

2000或Windows Server 2003提供网络负载均衡服务，但该服务的设置非常复杂。而通过DNS服务器实现网络负载均衡则是一种比较简单的方法。

　　企业网通常由很多子网构成，为了降低网络中的数据流量，客户机最好能访问处于同一子网内的Web服务器。虽然实现了网络负载均衡功能，但并不能保证客户访问的是本子网的Web服务器。其实这个问题也很好解决，只要启用DNS服务器的“启用网络掩码排序”功能即可。在DNS管理器窗口中，右键点击DNS服务器，在弹出的菜单中选择“属性”，然后在属性对话框中切换到“高级”选项卡，勾选“服务器选项”列表框中的“启用网络掩码排序”选项即可。这样客户机每次都能访问到本子网内的Web服务器了。完成以上设置后，就使DNS服务器实现了网络负载均衡功能，把客户的访问分担到每个Web服务器上，并且还减少了跨子网的网络通信流量，大大降低了企业网的通信负担。

　　4、企业实现SQL Server数据库服务器负载均衡

　　MS SQL

Server数据库服务器可以说是应用范围最广的数据库产品，并且越来越多地在大型和比较关键的应用系统中提供服务。当企业应用越来越复杂、数据量越来越大的时候，SQL

Server数据库要不停的进行处理、存储、查询的工作，这个时候企业就要考虑SQL Server数据库服务器的性能和速度及安全性了。然而，长期以来，SQL

SERVER数据库服务器都只有“热备”的解决方案，而没有“负载均衡”和“集群”的解决方案。

　　随着数据库路由器软件ICX的出现，为基于MS SQL Server的数据库系统提供了一种更优秀的集群解决方案。它可以真正的实现SQL

Server数据库服务器的动态负载均衡，提高性能和速度;它可以真正的保证SQL

Server数据库服务器不间断的提供服务，在服务器发生故障的时候实时切换到其他服务器上继续提供服务，切换时间为“零”。数据库路由器是实时并发数据库事务处理同步复制器和负载平衡器。

　　所有的数据库客户都通过ICX访问数据库。当访问、查询SQL

Server数据库的时候ICX可以根据实际情况分配服务器来提供服务，大大提高服务速度和优化性能，完成负载均衡。ICX可以同时连接多台数据库，这若干台数据库的内容在任何时刻由ICX保证是完全一致的。也就是说，ICX采用了全新的并发事务处理的方式，向连接的N台数据库同步复制事务处理，使得系统在任何时刻具有多个一致的最新逻辑数据库数据集。当其中一台数据库服务器发生故障的时候，ICX可以实时的、第一时间切换到其他服务器上来继续提供服务。真正的实现零时间的服务器切换，大大提高安全性，真正意义的实现服务器不间断服务。

5：当然自己可以DIY：用f5的网络负载均衡硬件和sql

server的复制技术软件可以实现负载均衡，故障切换则需要windows的cluster或者sql server

2005的mirror。除了那个f5的硬件外，整个方案成本其实很低。

它们是按SMP、NUMA、MPP、集群、分布处理从最紧密到最松散的排列。　　SMP(多处理系统):这种系统是在一台计算机里有多个CPU,CPU之间的地位是平等的，它们共享内存空间和I/O设备。其工作方法是由操作系统负责将任务分解成多个并发进程，然后让其在不同的CPU上运行。　　NUMA(非统一内存存取):这种系统可以让多处理计算机的CPU比SMP更高效地共享本地内存，CPU可以更快速地存取单一的内存区域，不过如需要也可以用间接方式存取其他区域的内存，这种方法是让某些CPU在给定范围的物理内存中有更大的优先使用权。　　MPP(巨型并行处理):这种系统的节点都有自己的CPU，并有自己的专有资源。此种结构相对独立，但各个节点一般没有完全存取I/O的能力。　　集群:集群系统是由独立的计算机组成，但有控制管理工具统一管理。　　分布处理:它是比我们要构筑的集群系统更松散的连接，一般是任务在不同的地方完成，没有可以作为整体管理的单一实体。　　以上的聚合方式有紧有疏，它们都有自己的适用范围，这里就不多说了，有兴趣可自己找些资料看，这里只是想让大家了解它所处的位置。　　实现负载均衡的方法　　集群的目的是共享和高效地利用资源，提供大型运算，提供负载均衡分配请求压力以及出现故障时能够进行切换实现高可用性。　　限于篇幅，本文只对负载均衡的实现做些介绍(针对TurboLinux Cluster Server)。通过对相关软件的分析，实现集群负载的功能是通过流量管理实现的，具体有这样几种实现方法:直接路由(Direct forwarding)、网络地址转换(NAT)、隧道技术(Tunneling)。　　直接路由(Direct forwarding)　　当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法，控制管理的计算机接收到请求包时直接送到参与集群的节点。优点是返回给客户的流量不经过控制主机，速度快开销少。　　网络地址转换(NAT)　　这种方法可能大家较熟悉，地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址，外界看起来包是来自地址转换器本身，当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。优点是节省IP地址，能对内部进行伪装;缺点是效率低，因为返回给请求方的流量经过转换器。　　隧道技术(Tunneling)　　这种方式是在集群的节点不在同一个网段时可用的转发机制，是将IP包封装在其他网络流量中的方法，为了安全的考虑，应该使用隧道技术中的***,也可使用租用专线。　　集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务、Proxy服务器等等，下面我们将就具体的产品TurboLinux Cluster Server 来实现一个进行负载均衡集群系统，用于提供Web和FTP的服务。　　四台服务器的负载均衡实例　　所提供的服务:Web、FTP。　　系统的实现目的:做一个较完善负载均衡的系统，以便能用到其中的较多的功能。　　采用设备状况:使用四台服务器，其中3台装TurboLinux Cluster Server,1台安装Windows 2000 Sever。　　系统安装　　1在两台服务器上安装TurboLinux， apache和wu-ftpd也要安装，因为集群要提供这种服务,安装完后重启，挂接光驱在目录/mnt/cdrom下，执 行/TLCS-install,然后按提示完全安装。

Nginx负载均衡服务器： IP：19216804（Nginx-Server）

Web服务器列表：

Web1: 19216805（Nginx-Node1/Nginx-Web1）

Web2:19216807（Nginx-Node2/Nginx-Web2）

实现目的：用户访问Nginx-Server时，通过Nginx负载均衡到Web1和Web2服务器。

配置注释如下：

创建文件夹准备存放配置文件

启动负载均衡服务器19216804（Nginx-Server）

创建文件夹用于存放web页面

编辑内容如下：

启动19216805（Nginx-Node1/Nginx-Web1）

创建文件夹用于存放web页面

编辑内容如下：

启动19216807（Nginx-Node2/Nginx-Web2）