Nginx基础详解5（nginx集群、四七层的负载均衡、Jmeter工具的使用、实验验证集群的性能与单节点的性能）

我们举一个例子，现在老板雇了一个工人，但是有10块砖，一个工人就会将他搬完；如果工人生病上不了班了，那么砖头就没有去搬了，就会造成单节点故障；多节点相当于老板雇了多个工人共同搬10块砖，这样的好处就是效率提高了好几倍，并且当一个工人生病请假的时候不会影响整体的工作，虽然效率有所下降，但是工作能正常运行（单节点经过水平扩容就会变成集群）。

14.2单节点和集群的比较

单节点模式：

优点：

配置简单，操作简单。

性能高，因为没有网络开销和数据同步的延迟。

成本低，没有备用节点，不需要其他的开支。

缺点：

数据容量受限于单台服务器的内存大小，无法进行横向扩展。

数据安全性低，一旦服务器宕机或者数据损坏，会造成数据的丢失或不一致。

可用性低，没有冗余备份，无法实现故障转移和负载均衡。

可靠性保证不是很好，单节点有宕机的风险。

单机高性能受限于CPU的处理能力，Redis是单线程的。

集群模式：

优点：

提供了更好的扩展性，可以通过增加更多的节点来提高处理能力和存储容量。

提高了系统的可用性和容错性，一个节点的故障不会导致整个系统的崩溃。

可以实现负载均衡，分散请求到多个节点，提高性能。

适合于需要高可用性、可扩展性和可靠性的应用场景。

缺点：

配置和维护复杂，需要处理节点之间的协调和数据同步。

成本高，需要更多的硬件资源和软件许可。

可能存在数据一致性问题，需要额外的机制来保证数据的一致性。

网络分裂和脑裂可能导致数据不一致。

综上：我们总结出一个道理，在经济条件允许的情况下，两台2核4G的性能一定大于一台4核心8G的服务器的性能，因为两个及以上的服务器可以进行集群的操作，有1+1>2的效果！

14.3Nginx中的负载均衡模块

nginx中使用upstream模块来控制自身的负载均衡，当客户端发来请求的时候，由nginx反向代理服务器发送到相关的网页服务器tomcat中，而这些tomcat共同组成了一个集群，那是哪台服务器优先接收到请求报文呢？这就涉及到Nginx具体的负载均衡算法了，先总述一下nginx的负载均衡共有至少6种方法（地域负载均衡、权重、轮询、hash、一致性hash、ip_hash、uri_hash）等等方法来解决集群高负载问题。很快我们就会讲解到。

15.四层、七层与DNS负载均衡

15.1四层负载均衡和七层负载均衡的概念

15.1.1四层负载均衡

在网络中第四层为传输层，所以该层的负载均衡是基于TCP/UDP报文的，是在OSI模型的传输层（TCP/UDP）上进行的。基本的实现形式为IP地址+端口号这种方法，建立一个连接之后该链接并不会消失直到会话结束才会消失，这也是我们之前讲到过的"长链接"，长链接的使用大大提高了nginx的转发效率。

以下是第四层负载均衡的一些关键特点和工作原理：

基于连接：第四层负载均衡器在建立连接时工作，它可以根据目标IP地址和端口号来决定将流量转发到后端服务器池中的哪一台服务器。

长连接：在长连接（Persistent Connection）模式下，负载均衡器为每个客户端请求创建一个连接，并在请求结束后关闭连接。这种方式可以减少频繁建立和断开连接的开销，提高效率。

会话保持：为了确保用户在多次请求中与同一服务器进行通信，第四层负载均衡器可以实现会话保持（Session Persistence）或会话亲和性（Session Affinity）。这通常是通过在负载均衡器上存储会话信息并将其与特定的后端服务器关联起来实现的。

健康检查：负载均衡器会定期对后端服务器进行健康检查，以确保它们能够处理新的连接。如果检测到服务器不健康，负载均衡器会停止将流量发送到该服务器，直到它恢复正常。

负载均衡算法：第四层负载均衡器使用各种算法来决定如何分发流量，常见的算法包括轮询（Round Robin）、最少连接（Least Connections）、加权轮询（Weighted Round Robin）和加权最少连接（Weighted Least Connections）等。

透明性：在某些配置中，第四层负载均衡器对客户端是透明的，客户端不需要知道负载均衡器的存在。在其他配置中，客户端可能需要配置DNS以指向负载均衡器的IP地址。

性能：由于第四层负载均衡器仅处理IP地址和端口号，它通常能够提供高性能的流量分发，尤其是在处理大量并发连接时。

安全性：第四层负载均衡器可以提供基本的安全功能，如基本的访问控制列表（ACLs）和防止某些类型的网络攻击。

15.1.2四层负载均衡的实现方法（仅作了解）

15.1.2.1F5硬负载均衡

F5是一种高性能的硬件负载均衡器，它通过智能地分配用户请求到后端服务器集群中的多个节点来实现负载均衡。F5支持多种负载均衡算法，包括轮询、最小连接、基于资源的以及基于IP散列等。F5还提供会话保持功能，确保同一用户的请求能够被送往同一后端服务器，以及SSL卸载功能，减轻后端服务器的计算负担。

15.1.2.2LVS四层负载均衡

LVS（Linux Virtual Server）是一个开源的负载均衡解决方案，它可以在Linux内核中实现网络负载均衡。LVS支持多种工作模式，包括NAT、DR、TUN和FULL-NAT模式。每种模式都有其特定的应用场景和配置方式。LVS通过ipvsadm工具进行配置和管理，支持多种调度算法，如轮询、最少连接等。

15.1.2.3Haproxy四层负载均衡

HAProxy是一个开源的高性能负载均衡器，它可以在TCP和HTTP层面上进行负载均衡。HAProxy支持丰富的配置选项，包括多种负载均衡算法、健康检查、会话保持等。HAProxy的配置简单，性能高效，适用于需要高并发处理的场景。

15.1.2.4Nginx四层负载均衡

Nginx不仅是一款优秀的Web服务器，也可以通过Stream模块实现四层负载均衡。Nginx的Stream模块允许进行TCP和UDP的代理和负载均衡。配置Nginx进行四层负载均衡非常简单，只需要在配置文件中定义upstream和server块即可。Nginx的四层负载均衡同样支持多种负载均衡算法，如轮询、最少连接等。

15.1.3七层负载均衡

在网络中第七层为应用层，所以该层的协议是基于HTTP协议的，也是基于URL和IP所进行的负载均衡。

15.1.4四层和七层之间的比较

四层负载均衡（黄牛）

四层负载均衡就像是一群黄牛在剧院门口卖票。他们只关心两件事情：谁在买票（IP地址）以及他们想要哪种票（端口号）。黄牛们并不在乎这场演出是什么内容，也不关心买家是谁，他们只是按照先来先服务的原则，将票卖给下一个人，并从他们手中收取费用。如果某个黄牛（服务器）太忙了，其他的黄牛就会接管新的买家，以确保每个人都能尽快买到票。

优点：快速、高效，不需要了解太多细节。

缺点：缺乏灵活性，无法根据票的种类（内容）或买家的偏好做出更智能的决策。

七层负载均衡（售票处）

七层负载均衡则像是剧院内部的售票处。售票员不仅知道剧院的座位布局（服务器的健康状况和负载情况），还了解不同演出的详细信息（应用层的内容，如HTTP头、URL等）。他们可以根据演出的热度、座位的可用性、甚至是买家的会员等级来分配座位（请求）。如果某个区域的座位已经满了，或者某个演出非常受欢迎，他们可以将更多的买家引导到这些区域。

优点：更加智能和灵活，可以根据复杂的规则和策略来分配请求。

缺点：处理每个请求需要更多的信息和时间，可能会稍微降低效率。

15.1.5七层负载均衡的实现方法

15.1.5.1Nginx实现负载均衡（仅作了解）

Nginx在七层负载均衡中就像是一个现代化的电子售票系统。它可以根据用户的浏览历史、购票偏好、甚至实时的流量情况来推荐座位。Nginx通过检查HTTP请求头来决定将请求转发到哪个服务器，并且可以缓存常见的响应来提高效率。

15.1.5.2Haproxy实现负载均衡

HAProxy则像是一个经验丰富的售票主管，它不仅了解每场演出的细节，还能够实时监控每个售票员（服务器）的状态。HAProxy可以根据实时数据来优化票的分配，确保每个买家都能得到最佳的座位，同时保持剧院的运营效率。

15.1.5.3apache实现负载均衡

Apache作为一个负载均衡器，就像是一个传统的售票处，它遵循先来先服务的原则，但也提供了一些基本的调度策略，比如根据演出的类型或者座位区域来分配票。Apache可能没有Nginx或HAProxy那样灵活，但它稳定且易于配置。但是如果呈现上百万的买票者（访问量）的话，apache也是扛不住的，性能会持续下降。

15.2地域负载均衡的原理

当我们客户端想要访问某个服务器的时候，该服务器在全国有两个（假设），北京一个、上海一个。假设我们的客户端在河北，你认为会分配到上海的服务器吗？

显然不会（如果你不可以去分配上海的服务器或者北京的服务器没坏），我们在发送请求的时候将我们自身的IP地址发送到DNS服务器之后DNS会根据服务器的就近原则还给你一个最近服务器的公网的IP地址。反之我们到南方访问某服务器还是会根据地域分配给你一个相应的IP地址。

++如果还是不明白的话大家玩过Steam游戏吧，游戏内我们想要挂加速器的话是不是"内港澳台韩日新"这些位置的服务器速度比较快，如果你挂一个瑞士的服务器或者挂到南美洲，相比之下速度是不是没有距离我们近的服务器速度快？这也是地域负载均衡的一种体现，距离近的服务器速度快、体验好。++

15.2.1地域负载均衡的优势（仅作了解）

降低延迟：通过将用户请求路由到最近的服务器，减少数据传输距离，从而降低延迟，提高用户体验。

提高可用性：如果一个地区发生故障，流量可以被重定向到其他地区的服务器，保证服务的连续性。

优化资源利用：可以根据每个地区的用户访问量和服务器性能，合理分配资源，提高资源利用率。

增强容灾能力：在不同地理位置部署服务器，可以在自然灾害或其他不可预见的事件发生时，保证服务不受影响。

支持灵活的流量管理：可以根据实际需求，灵活地调整流量分配策略，以应对不同的业务场景。

提高安全性：可以通过负载均衡设备在七层进行安全策略的设置，过滤特定报文，提高系统整体安全。

支持业务增长：随着业务的扩展，可以在新的地区部署服务器，并通过地域负载均衡进行流量分发，支持业务的全球化发展。

成本效益：通过合理分配流量，可以避免过度依赖单一数据中心，降低成本。

支持混合云部署：可以与云服务提供商的全球网络结合，实现云资源和本地资源的优化配置。

16.jmeter工具测试网站抗负载能力

++我们网站搭建好了之后如何完成测试呢？假设我们想要测一测网站是否可以满足200个人同时各发送100个请求共20000各请求，网站服务器能不能扛得住呢？异常率是多少？单体和集群的数据上的差别到底在哪里？++这就用到了我们测试工具Jmeter了。

16.1Jmeter的安装

先找到下载地址"点我下载Jmeter"进入的主界面如下图

下载完成之后找到本地的安装包并解压，找到Jmeter-server.bat工具双击即可运行，如果您是Mac用户双击jmeter打开后的界面如下

16.2Jmeter的使用

第一步：新建测试文件并保存

在TestPlan中可以修改测试计划的名称，我们将其改为单节点tomcat，修改后保存到某一位置。我保存到了D盘的JmeterTestProject目录下了。

第二步：新建++线程组++并编辑

编辑线程组的内容（例子为50个用户将在1秒内全部启动，每个用户将发送100个请求，总共是5000个请求。这些请求将在整个测试期间发送，直到所有用户都完成了他们的100个请求。）

第三步：添加取样器并编辑（右击线程组1->Add->Sampler->Http Request）表示我们添加了取样器（Sampler）中的http请求的取样器（还可以对其他类型进行取样，我们先实验对http报文进行取样）

接下来我们编辑取样器

第四步：添加聚合报告

第五步：添加查看结果树

第六步：添加用"表格查看结果"

完成之后的界面如下

16.3开始结果测试并查看结果

单击上方Start绿色按钮开始结果测试，我们可以查看测试完成后的聚合报告

对于下方13列的信息我来给大家解释一下：

Label: 这是图表的标签，通常用于描述图表的内容。

Samples: 表示采样次数，即请求的总数。

Average: 平均值，所有请求的平均响应时间（单位为毫秒）。

Median: 中位数，所有请求响应时间的中值，表示一半请求比这个值快，一半请求比这个值慢（单位为毫秒）。

90% Line: 90%表示5000个请求中第90%个报文的响应时间或第90%个报文的平均响应时间（单位为毫秒）。

95% Line: 95%表示5000个请求中第95%个报文的响应时间或第95%个报文的平均响应时间（单位为毫秒）。

99% Line: 99%表示5000个请求中第99%个报文的响应时间或第99%个报文的平均响应时间（单位为毫秒）。

Min: 最小值，所有请求中的最小响应时间。

Maximum: 最大值，所有请求中的最大响应时间。

Error%: 错误率，失败请求占总请求的百分比。

Throughput: 吞吐量，单位时间内完成的请求数，通常以每秒完成的请求数（requests/sec）来表示。

Received KB/sec: 每秒接收的数据量（以KB为单位）。

Sent KB/sec: 每秒发送的数据量（以KB为单位）。

11-13列与网络带宽挂钩，带宽越大，这三列性能越高

显然，50个请求对于tomcat还是吃得消的，但如果我们将请求的用户数量增大呢？50-->200

再来查看报告

这时我们发现Maximum数值变得异常大，如果以毫秒为单位的话相当于4s多了，在计算机中4s算是相当长的时间了，所以我们单台tomcat对于多用户的请求会慢慢的吃不消。

我们再来分析一下结果树的信息

16.1结果栏（Sampler result）

Thread Name: 线程的名称，例如线程图1 1-396，这可能表示在JMeter测试计划中的第一个线程组中的第396个线程。

Sample Start: 样本开始时间，例如2024-10-02 11:19:39 CST，表示请求发送的时间。

Load time: 请求的加载时间，这里为7毫秒。

Connect Time: 建立连接所需的时间，这里为0毫秒。

Latency: 延迟时间，从发送请求到收到第一个响应字节的时间，这里为7毫秒。

Size in bytes: 响应的总字节大小，这里为7858字节。

Sent bytes: 发送的字节数，这里为117字节。

Headers size in bytes: 响应头的大小，这里为310字节。

Body size in bytes: 响应体的大小，这里为7548字节。

Sample Count: 样本计数，这里为1，表示这个请求被执行了一次。

Error Count: 错误计数，这里为0，表示没有错误。

Data type: 响应数据的类型，这里为text和binT，text表示文本数据，bin是二进制数据。

Response code: 响应代码，200表示HTTP请求成功。错误则显示一段英语Non......

Response message: 响应消息，OK表示请求成功。

HTTPSampleResult fields: 这是一系列与HTTP请求结果相关的字段。

ContentType: 内容类型，text/html;charset=UTF-8表示响应的内容类型是HTML，字符编码是UTF-8。

DataEncoding: 数据编码，这里也是UTF-8。

16.2请求栏

上图为请求报文的内容

上图为请求体内容

16.3响应栏（相应成功后Response Body显示网页内容）

相应成功后显示的响应报头

16.4实验：对比集群服务器与单体服务器在访问上的区别

实验前提：我们有两台服务器，一台tomcat服务器，另一台nginx服务器（nginx服务器上也配置了tomcat服务），tomcat服务器的ip为192.168.154.140，nginx服务器的IP地址为192.168.154.142，现在我们将这两个服务器设置成一个集群来使用，使用Jemeter服务测试集群服务器是否比单台服务器的性能高。

并且我们将tomcat服务器编写上h1标签为tomcat1，nginx服务器编写上标签为tomcat2，重复刷新界面我们发现既可以刷新到tomcat1的界面，也可以刷新到tomcat2的界面。

需要注意的是：我们手动编辑tomcat的默认界面的位置在

apache-tomcat的目录下/webapp/ROOT/index.jsp

我们在nginx中nginx.conf的配置如下图所示

接下来我们使用测试工具Jmeter对网页进行访问测试，并与先前的单台进行对比：

集群的结果如下

单台的结果如下

我们发现最后三列不论是吞吐量还是数据的收发能力都是集群的服务器高。重复刷新界面查看显示的网页一样吗？我们发现不一样！相同的ip却是访问到了两台tomcat服务器，这正是负载均衡最简单的、最有力的证明！