多台异地服务器如何实现负载均衡？

一般用的就用简单的轮询就好了

调度算法

静态方法：仅根据算法本身实现调度；实现起点公平，不管服务器当前处理多少请求，分配的数量一致

动态方法：根据算法及后端RS当前的负载状况实现调度；不管以前分了多少，只看分配的结果是不是公平

静态调度算法(static Schedu)（4种）:

(1)rr (Round Robin) :轮叫,轮询

说明：轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。缺点：是不考虑每台服务器的处理能力。

(2)wrr (Weight Round Robin) :加权轮询(以权重之间的比例实现在各主机之间进行调度)

说明：由于每台服务器的配置、安装的业务应用等不同，其处理能力会不一样。所以，我们根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。

(3)sh (Source Hashing) : 源地址hash实现会话绑定sessionaffinity

说明：简单的说就是有将同一客户端的请求发给同一个real server,源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的并且没有超负荷，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。

(4)dh : (Destination Hashing) : 目标地址hash

说明：将同样的请求发送给同一个server,一般用于缓存服务器，简单的说，LB集群后面又加了一层，在LB与realserver之间加了一层缓存服务器，当一个客户端请求一个页面时,LB发给cache1,当第二个客户端请求同样的页面时，LB还是发给cache1,这就是我们所说的，将同样的请求发给同一个server,来提高缓存的命中率。目标地址散列调度算法也是针对目标IP地址的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

动态调度算法(dynamic Schedu)（6种）:

(1)lc (Least-Connection Scheduling): 最少连接

说明：最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以有了下面算法wlc。

简单算法：active256+inactive (谁的小，挑谁)

(2)wlc (Weighted Least-Connection Scheduling):加权最少连接

加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接收到更多的请求。

简单算法：（active256+inactive）/weight（谁的小，挑谁）

(3)sed (shortest expected delay scheduling):最少期望延迟

说明：不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。

基于wlc算法，简单算法：（active+1)256/weight （谁的小选谁）

(4)nq (Never Queue Scheduling): 永不排队

说明：在上面我们说明了，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，所此算法是sed改进，就是说不管你的权重多大都会被分配到请求。简单说，无需队列，如果有台real server的连接数为0就直接分配过去，不需要在进行sed运算。

(5)LBLC(Locality-Based Least Connections) :基于局部性的最少连接

说明：基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度，主要用于Cache集群系统，因为Cache集群中客户请求报文的目标IP地址是变化的，这里假设任何后端服务器都可以处理任何请求，算法的设计目标在服务器的负载基本平衡的情况下，将相同的目标IP地址的请求调度到同一个台服务器，来提高服务器的访问局部性和主存Cache命中率，从而调整整个集群系统的处理能力。

(6)LBLCR(Locality-Based Least Connections with Replication) :基于局部性的带复制功能的最少连接

说明：基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。

1、服务直接返回：这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。

2、桥接模式：桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。

3、路由模式：路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

扩展资料

负载均衡的算法:

1、随机算法：Random随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

2、哈希算法：一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

3、URL散列：通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。

参考资料

-负载均衡

当前环境快照

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

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

对原始服务器做一次性复制，而不需要再次安装和配置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 ON wordpress 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地址或域名访问!

你上面说到的这些服务器只有Web服务器需要做负载均衡，而且一般都是前置机才做负载均衡，做服务器负载均衡的条件是：

1 你要有提供相同应用的多台Web服务器。

2 要有负载均衡的设备（可以是软件也可以是硬件）。

3 要为这个服务分配一个虚拟地址（作为服务访问的统一入口）和若干真实地址（有几台Web服务器需要几个真实地址）。

注：一般建议采用硬件设备，通常需要做负载均衡的应用说明他的负载很大，专用的硬件比较可靠。

具备以上条件后将Web服务器连接到负载均衡设备上，在负载均衡设备上配置虚拟地址和真实地址、配置负载均衡算法，配置负载均衡策略，将负载均衡设备接入网络。

这样，外面的用户只需要访问这个虚拟地址就可以了，负载均衡设备收到请求后会按照负载均衡策略和算法把请求分配到真实地址上，实现负载功能。

以上所说只是负载均衡的一种部署方式，根据实际需要选择单臂、双臂接入网络；根据应用的特点选择健康检查的方式；根据应用选择是否使用回话保持算法等。

负载均衡架构部分转自 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的过载保护

 1集群(Cluster)：是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。

  2负载均衡(Load Balance)：先得从集群讲起，集群就是一组连在一起的计算机，从外部看它是一个系统，各节点可以是不同的操作系统或不同硬件构成的计算机。如一个提供Web服务的集群，对外界来看是一个大Web服务器。不过集群的节点也可以单独提供服务。

  3特点：在现有网络结构之上，负载均衡提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。集群系统 (Cluster)主要解决下面几个问题：

  (1)高可靠性（HA）：利用集群管理软件，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务;

  (2)高性能计算（HP）：即充分利用集群中的每一台计算机的资源，实现复杂运算的并行处理，通常用于科学计算领域，比如基因分析，化学分析等;

  (3)负载平衡：即把负载压力根据某种算法合理分配到集群中的每一台计算机上，以减轻主服务器的压力，降低对主服务器的硬件和软件要求。