网站访问量已经越来越大，响应速度越来越慢。
考虑：

• Scale Up（也就是Scale vertically）纵向扩展，向上扩展：机器硬件升级，增加配置，如添加CPU、内存。（往往需要购置新机器）–>旧机器不能利用上。
• Scale Out（也就是Scale horizontally）横向扩展，向外扩展：向原有的web、邮件系统添加一个新机器。–>旧机器仍然可以发挥作用。

负载均衡技术为 scale out 服务。

DNS轮询

让我们网站的域名映射到多个 服务器IP，用户面对的是我们系统的域名，然后我们可以采用一种轮询的方式， 用户1的机器做域名解析的时候，DNS返回IP1, 用户2的机器做域名解析的时候，DNS返回IP2。

存在问题：DNS 这个分层的系统中有缓存，客户端机器也有缓存，如果某台机器出现故障，域名解析仍然会返回那个出问题机器的IP，就会出现错误。

负载均衡LVS的NAT原理

设置一个负载均衡服务器（Load Balancer ，LB）， 用户的请求都发给他，然后它再发给各个服务器。

LB ， 有两个IP，一个对外（115.39.19.22），一个对内(192.168.0.100)。用户看到的是那个对外的IP。 后面的真正提供服务的服务器有三个，称为RS1, RS2,RS3， 他们的网关都指向LB。

请求过程：
用户发了一个HTTP的请求，想要访问我们网站的首页，这个HTTP请求被放到一个TCP报文中，再被放到一个IP数据报中， 目的地是我们的 LB （115.39.19.22）。

Load Balancer想把这个数据包发给RS1（192.168.0.10），就需要把 IP数据报头部的目的地址和端口改为RS1的：

RS1处理完了，要返回首页的HTML，还要把HTTP报文层层封装，发给网关 LB：

LB收到返回的数据报后，需要把源地址和源端口都替换为自己的，然后发给客户：

客户端根本就感受不到后面有好几台服务器在工作，它一直以为只有Load Balancer在干活。

LB 选取后面真实的服务器转发 有很多策略，如：

• 轮询： 这个最简单，就是一个挨一个轮换。
• 加权轮询： 为了应对某些服务器性能好，可以让他们的权重高一点，被选中的几率大一点。
• 最少连接： 哪个服务器处理的连接少，就发给谁。
• 加权最少连接：在最少连接的基础上，也加上权重

由于IP数据报会在网络层分片传输，这些数据包如果被 LB 分发到不同的 真实服务器上就会乱套了，所以 LB 必须维护一张表，记录客户端的数据包被我们转发到了哪个真实的服务器上， 这样当下一个数据包到来时，我们就可以把它转发到同一个服务器上去。

可见 负载均衡软件需要是面向连接的，也就是OSI网络体系的第4层， 可以称为四层负载均衡。

存在的问题：所有的流量都要通过它，它要修改客户发来的数据包， 还要修改发给客户的数据包。
网络访问请求报文较短而响应报文往往包含大量的数据。这就进一步加剧了Load Balancer修改数据包的工作。

我们把请求和响应分开处理。

负载均衡LVS的DR原理

为了返回数据的时候不用再返回给LB修改 原地址，需要将每个服务器地址都设为公网地址。设为 VIP（115.39.19.22）。

这么多服务器IP相同，那么如何解决转发问题呢？
IP数据报的转发其实要通过MAC地址的，所以可以利用数据链路层的ARP协议。

当路由器需要转发 115.39.19.22 的数据包来的时候，发送ARP广播，请求MAC地址，只让Load Balancer 响应这个VIP地址（115.39.19.22）的ARP请求，RS1,RS2,RS3, 抑制住对这个VIP地址的ARP响应。LB得到这个数据报。它就可以用某个策略从RS1, RS2,RS3中选取一个服务器，例如RS1（192.168.0.10），把IP数据报原封不动， 封装成数据链路层的包（目的地是RS1的MAC地址），直接转发。RS1（192.168.0.10）这个服务器收到了数据包，处理完了以后，RS1可以直接响应发回给客户端，完全不用再通过Load Balancer。因为自己的地址就是115.39.19.22。

双机热备

上面的负载均衡方案，存在单点失败（Single Point of Failure）的风险。 LB只有一条服务器，如果出现问题，真实服务器也无法发挥作用。

上两台Load Balancer，实行双机热备。两个Load Balancer 最好是一个整体，就像一个虚拟的服务器， 这个虚拟的服务对外提供一个IP (简称VIP)。 平时Master 负责干活， Backup待命，一旦Master挂掉， Backup 服务器立刻接管。

怎么才能实现在两个服务器之间的“IP漂移”呢？
一个网卡可以设置多个地址，比如在Linux上eth0表示网卡1，它可以绑定一个IP， 与此同时，还可以设置一个ip alias 或者 secondary ip ：
eth0 –> 192.168.1.10
eth0:1 –> 192.168.1.100

我可以让这个192.168.1.100为VIP，如果服务器是Master， 就可以把这个IP给绑定上， 如果是Backup，那就不绑定。
通过动态地绑定/解绑 就可以让这个VIP在两个服务器之间来回“漂移”了。

Backup 怎么知道Master 挂掉了呢？
只需要让Master不断地给Backup发“心跳”消息即可(可以采用广播的方式发消息)， 这个Backup(LoadBalancer2) 得有个定时器， 如果在一个特定的时间（嗯，这个时间应该可以设置）内收不到心跳，那就认为Master完蛋了，就动态地绑定VIP，开始提供服务。

如果原Master又活了呢，如果LoadBalancer1是个性能更加强悍的机器，就需要重新切换回去，所以还需要定义一个策略，每个机器都得有个优先级（一个整数），在允许抢占的情况下，谁的优先级高，谁就是Master！所以需要软件实现这些通信“协议”和策略， 这个软件需要安装运行在每个Load Balancer上，让他们组成单个虚拟的Load Balancer， 对外提供服务。

但是 IP包是被封装在以太网帧中发送的，其中需要MAC地址。

在发送第一个请求的时候，客户端（确切说是直接向Load Balancer发数据的那个机器）先是知道了VIP（如：192.168.1.100）， 接下来它需要知道这个VIP的MAC地址，这样才能发送数据。

为了拿到MAC地址，它需要发起ARP查询： 这个VIP（192.168.1.100)的 MAC的地址是什么？
如果Load Balancer 1是Master ，就会回复： 是23:39:8D:9C:0A:33 （记为 MAC1）
这时候客户端就会缓存，记下来。
然后Load Balancer 1 挂掉， Load Balancer 2 成为 Master。
此时客户端如果再次发送数据，还会往MAC1去放送，于是就出错了。

所以 Master 和 Backup 需要虚拟相同的MAC地址。哪个机器成为Master， 每次响应ARP请求的时候，都返回这个虚拟的MAC地址。

Master 和 Backup 需要相同的IP和MAC地址。
虚拟IP + 虚拟的MAC 地址才能完整地解决问题。
虚拟IP靠网卡的动态绑定/解绑。
虚拟MAC也类似。

四层负载均衡和七层负载均衡

负载均衡集群是 Load Balance 集群。是一种将网络上的访问流量分布于各个节点，以降低服务器压力，更好的向客户端提供服务的一种方式。常用的负载均衡。

• 开源软件有Nginx、LVS、Haproxy (ngnix和haproxy是七层负载均衡，LVS是四层负载均衡)
• 商业的硬件负载均衡设备F5、Netscaler。

简单的理解一下软件负载均衡。
①.所谓分层的负载均衡，都是以网络的模型来说的。四层就是基于IP和端口的负载均衡，七层就是基于URL等应用信息的负载均衡。所以简单的说四层负载均衡就是通过IP和端口接收请求再分发至真实的服务器，七层是通过URL或主机名接收请求，然后分发至真实的服务器。

②.七层的实现也是在四层的基础上是实现的，没有四层就不可能有七层。在第七层上可以做许多事情，比如可以根据七层的浏览器类别区分是手机还是PC，将WEB服务器分为2组，手机登陆专门的移动端网站。

③.对客户端来说，客户端好像是访问的同一台主机。其实为了有更好的用户体验，从智能DNS入手，根据客户端IP来源将域名解析到距离客户端最近的一台服务器或者访问最快速的一台服务器，但这些内容客户端都是感觉不到的，客户端感觉到的只能是访问网站很快。

三种开源负载均衡器的特点：

LVS特点是：
1. 首先它是基于4层的网络协议的，抗负载能力强，对于服务器的硬件要求除了网卡外，其他没有太多要求；
2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，大大减少了人为出错的几率；
3. 应用范围比较广，不仅仅对web服务做负载均衡，还可以对其他应用（mysql）做负载均衡；
4. LVS架构中存在一个虚拟IP的概念，需要向IDC多申请一个IP来做虚拟IP。

Nginx负载均衡器的特点是：
1. 工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
2. Nginx安装和配置比较简单，测试起来比较方便；
3. 也可以承担高的负载压力且稳定，一般能支撑超过上万次的并发；
4. Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
5. Nginx对请求的异步处理可以帮助节点服务器减轻负载；
6. Nginx能支持http和Email，这样就在适用范围上面小很多；
7. 默认有三种调度算法: 轮询、weight以及ip_hash（可以解决会话保持的问题），还可以支持第三方的fair和url_hash等调度算法；

HAProxy的特点是：
1. HAProxy是工作在网络7层之上；
2. 支持Session的保持，Cookie的引导等；
3. 支持url检测后端的服务器出问题的检测会有很好的帮助；
4. 支持的负载均衡算法：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)；
5. 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度；
6. HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

参考：https://mp.weixin.qq.com/s?__biz=MzIxMjE5MTE1Nw==&mid=2653194054&idx=1&sn=36f476f2e2f14cd14ad44326b8df4cba&chksm=8c99f59cbbee7c8aa99485fe85f788e118c62b2492b0a55901fa64700bed26b6d355806aecbf&scene=0#rd
https://blog.csdn.net/ghost_leader/article/details/55827729