Linux的负载均衡详解

Linux的负载均衡常用的有三种技术：中国人搞出来的大神级产品 LVS Linux Virtual Server，俄罗斯的Nginx，来发法国的HAProxy。都是基于Linux的开源免费的负载均衡软件。

1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低

2. 工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。

3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4. 不支持正则处理，不能做动静分离。

5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)

6. 配置相对复杂，对网络依赖比较大，稳定性很高。

7. LVS工作模式有4种：

    (1) nat 地址转换

    (2) dr 直接路由

    (3) tun 隧道

    (4) full-nat

1. 工作在网络7层，可以针对http应用做一些分流的策略，比如针对域名，目录结构

2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能

3. Nginx安装配置比较简单，测试起来很方便

4. 也可以承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的

5. 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测

6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力

7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。

8. 不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。

9. Nginx还能做Web服务器即Cache功能。

1.支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；

2.能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

3.支持url检测后端的服务器出问题的检测会有很好的帮助。

4.更多的负载均衡策略比如：动态加权轮循(DynamicRoundRobin)，加权源地址哈希(Weighted SourceHash)，加权URL哈希和加权参数哈希(WeightedParameterHash)已经实现

5.单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

6.HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

7.支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

8.不能做Web服务器即Cache。

1. 负载能力

lvs抗负载能力最强，因为仅作分发不处理请求，相当于只作转发不做进一步处理直接在内核中完成，对系统资源消耗低（LVS DR模式）；

nginx和haproxy相对来说会弱，但是日PV2000万也没什么问题，因为不仅接受客户端请求，还与后端upstream节点进行请求并获取响应，再把响应返回给客户端，对系统资源和网络资源消耗高；

注：建议如果公司网站流量日PV在2000万以上，并发在7，8万以上才考虑用lvs+keepalived架构

2. 功能性

lvs仅支持4层tcp负载均衡，haproxy可以支持4层tcp和7层http负载均衡，nginx可以支持7层http负载均衡（新版本也支持7层负载均衡）；

nginx功能强大，配置灵活，可做web静态站点，静态缓存加速，动静分离，并支持域名，正则表达式，Location匹配，rewrite跳转，配置简单直观明了，还可以结合etc或consule做发布自动化上下线等等；

haproxy相对nginx的7层负载均衡会弱一些，灵活性不足，个人建议一般用haproxy做TCP负载均衡更合适一些；

3. 运维复杂度

lvs相对来说部署架构更复杂一些，lvs对网络是有要求，lvs必须与real server在同一个网段，也更费资源，需要多2台服务器成本；

nginx和haproxy部署架构更简单，对网络也没要求，更便于后续维护；

像对于大型的，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx；

对于大型的Web服务器的时候可以使用haproxy；

对性能有严格要求的时候可以使用lvs，就单纯从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司。

注：lvs,nginx,haproxy要实现高可用，都需要借助keepalived软件

1、查看Linux系统CPU个数

2、每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令

2.1、如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。​

2.2、但如果1分钟的值远小于15 分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。

2.3、反过来，如果1分钟的值远大于 15 分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

​​eg：假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。​ ​

2.4、当平均负载高于 CPU 数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。​

2.5、CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应

2.5.1、CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；

2.5.2、I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；

2.5.3、大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。

3、使用工具iostat（stress）、mpstat、pidstat 等工具，找出平均负载升高的根源

3.1、stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景​​

3.2、而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。​

3.2.1、mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有CPU的平均指标。

3.2.2、pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标

首先，在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景

接着，在第二个终端运行uptime查看平均负载的变化情况

最后，在第三个终端运行mpstat查看 CPU 使用率的变化情况

那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询

首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync

还是在第二个终端运行uptime查看平均负载的变化情况

然后，第三个终端运行mpstat查看 CPU 使用率的变化情况

那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。比如，我们还是使用 stress，但这次模拟的是 4 个进程

由于系统只有 1 个CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达3.71

接着再运行pidstat来看一下进程的情况

---