定义
Nginx是由俄罗斯的程序设计师Igor sysev开发的 轻量级的web服务和代理服务器，nginx拥有很高的并发处理能力，有报告说明能吃50000并发连接
特点
占用内存少、稳定、并发能力强
基于epool 事件驱动架构，使其支持百万级别的TCP连接
扩展性好，因为nignx是高度模块化且拥有自由软件许可证，使得很多第三方模块可以介入
支持跨平台，nginx 支持Linux，Windos
正向代理和反向代理
正向代理
客户端知道要访问的地址是什么而服务器只知道请求来自哪个服务器，不知道真实的客户端是什么，除非代理服务器将真实的客户端地址也代理过去
反向代理
反向代理，客户端对代理端是无感知的，客户端不需要配置任何东西就可以访问，只需要将请求发送的方向代理服务器就可以获取到后端真实服务数据，此时方向代理服务器和目标服务器对外是一体，暴露在外的是代理服务器地址，隐藏了真实服务器ip地址
示例
负载均衡
比如一个服务或者一台机器的性能有限，那么当访问量达到一定阙值的时候，我们就需要使用到负载均衡，也就是客户端发起的请求， 经过代理端，代理端会将请求根据一定的算法标准分发到后端的各个服务器上
示例
负载均衡策略
nginx的负载均衡用于upstream模板定义的后端服务器列表中选取一台服务器接收用户的请求。一个基本的upstream模块如下：
upstream [服务器组名称]{
server [IP地址]:[端口号];
server [IP地址]:[端口号];
....
}
在upstream模块配置完成后，要让指定的访问反向代理到服务器列表，格式如下：
location ~ .*$ {
index index.jsp index.html;
proxy_pass http://[服务器组名称];
}
这样就完成了最基本的负载均衡，但是这并不能满足实际需求。
目前Nginx的upstream模块支持6种方式的负载均衡策略（算法）：
轮询
最基本的配置方法，是upstream模块默认的负载均衡策略。每个请求会按时间顺序平均分配到不同的后端服务器。有如下参数：
fail_timeout 与max_fails结合使用
max_fails 在fail_timeout参数设置的时间内最大失败次数。如果在这个时间内，所有该服务器的请求都失败了，那么认为该服务器停机
fail_time 服务器被认为停机的时长，默认10s（被认为停机的服务器尝试间隔？）
backup 标记该服务器为备用服务器。当主服务器停止时，请求会被发送到它这里
down 标记服务器永久停机
注意：1.down标记的服务器会自动剔除；2.缺省就是轮询；3.此策略适合服务器配置无状态且短平块的服务使用
weight
权重方式，在轮询策略的基础上指定轮询的几率。也可以认为是在轮询的基础上新增了一个weight的参数，此参数指定轮询的几率，值为number。upstream模块配置模板如下：
upstream [服务器组名称]{
server [IP地址]:[端口号] weight=2;
server [IP地址]:[端口号];
....
}
在该例子中，没有weight参数的服务器默认为1，weight的数值与访问比例成正比，所有weight值的总和为一个循环单位，服务器自身的weight值为循环单位内的轮询次数。
注意：1.权重越高分配到的请求越多；
2.此策略可以和least_conn策略、iphash策略结合使用；
3.此策略比较适合服务器硬件配置差距较大的情况。
ip_hash
依据ip分配方式，指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端请求一致发送到相同的服务器，以保证session会话。这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题。upstream模块配置模板如下：
upstream [服务器组名称]{
ip_hash;
server [IP地址]:[端口号] weight=2;
server [IP地址]:[端口号];
....
}
注意：1.nginx1.3.1之前的版本不能在ip_hash中使用权重（weight）；2..ip_hash不能与backup同时使用；3.此策略适合有状态服务的程序，比如session；4.当有服务器需要剔除，必须手动down掉。
least_conn
最少连接方式，把请求发给链接数最少的后端服务器。轮询是把请求平均分配给各个后端，使它们的负载大致相同。但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。upstream模块配置模板如下：
upstream [服务器组名称]{
least_conn;
server [IP地址]:[端口号] weight=2;
server [IP地址]:[端口号];
....
}
注意：此策略适合请求处理时间长短不一造成的服务器过载情况。
fair
响应时间方式，按照服务器端的响应时间来分配请求，响应时间短的优先分配。upstream模块配置模板如下：
upstream [服务器组名称]{
server [IP地址]:[端口号] weight=2;
server [IP地址]:[端口号];
....
fair;
}
注意：需要安装第三方插件。
url_hash
url分配方式，按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再次收到请求，就可以在缓存中读取。upstream模块配置模板如下：
upstream [服务器组名称]{
hash $request_uri;
server [IP地址]:[端口号] weight=2;
server [IP地址]:[端口号];
....
}
动静分离
一般来说为了加快网站的解析速递，我们会吧动态页面和静态页面分开解析，降低单个服务器压力
下载
https://nginx.org/en/download.html
安装
基础环境安装
yum install gcc g++ pcre-devel zlib-devel openssl-devel openssl-devel -y
解压安装
[root@bot bak]# wget https://nginx.org/download/nginx-1.22.1.tar.gz
--2023-10-18 17:18:44-- https://nginx.org/download/nginx-1.22.1.tar.gz
Resolving nginx.org (nginx.org)... 3.125.197.172, 52.58.199.22, 2a05:d014:edb:5702::6, ...
Connecting to nginx.org (nginx.org)|3.125.197.172|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073948 (1.0M) [application/octet-stream]
Saving to: ‘nginx-1.22.1.tar.gz’
100%[=======================================================================================================================================================================================================>] 1,073,948 1.02MB/s in 1.0s
2023-10-18 17:18:46 (1.02 MB/s) - ‘nginx-1.22.1.tar.gz’ saved [1073948/1073948]
[root@bot bak]# tar xf nginx-1.22.1.tar.gz
[root@bot bak]# ll
total 1056
drwxr-xr-x 8 ftpuser yibot 4096 Oct 19 2022 nginx-1.22.1
-rw-r--r-- 1 root root 1073948 Oct 19 2022 nginx-1.22.1.tar.gz
[root@bot bak]#
需要注意的是这里解压出来的是源码需要经过编译才可以安装
参数解释
--prefix 指定nginx的安装目录
--pid-path 指定nginx 的pid
--lock-path 锁定安装文件，防止被恶意篡改或误操作
--error-log 错误日志
--http-log-pathhttp 日志
--with-http_gzip_static_module 启用gzip模块，在线实施压缩数据流
--http-client-body-temp-path 设定http代理临时目录
--http-fastcgi-temp-path 设定fastcgi的临时目录
--http-uwsgi-temp-path 设置uwsgi的临时目录
--http-scgi-temp-path 设置scgi的临时目录
编译安装
make && make install
启停
/usr/local/nginx/sbin/nginx
/usr/local/nginx/sbin/nginx -s stop
/usr/local/nginx/sbin/nginx -s reload 重启
测试
浏览器访问 服务器+80
常用的命令
目录结构
配置文件结构
配置属性说明
配置解释
和LVS对比
LVS
1-负载能力强，因为其工作方式逻辑非常简单，仅进行请求分发，而且工作在网络的第4层，没有流量，所以其效率不需要有过多的忧虑。
2-基本能支持所有应用，因为工作在第4层，所以LVS可以对几乎所有应用进行负载均衡，包括Web、数据库等。
3-LVS比较依赖网络环境。只有使用DR模式且服务器在同一网段内分流，效果才能得到保证
注意：LVS并不能完全判别节点故障，比如在WLC(无线局域网控制器)规则下，如果集群里有一个节点没有配置VIP，将会导致整个集群不能使用
Nginx
1-工作在网路第7层，所以可以对HTTP应用实施分流策略，比如域名、结构等。相比之下，LVS并不具备这样的功能，所以Nginx可使用的场合远多于LVS
2-Nginx对网络的依赖比较小，理论上只要Ping得通，网页访问正常就能连通。
3-Nginx可以通过服务器处理网页返回的状态吗、超时等来检测服务器内部的故障，并会把返回错误的请求重新发送到另一个节点。
4-LVS的安装、配置及测试所花的时间比较长，因为LVS对网络以来比较大，很多时候有可能因为网络问题而配置不能成功，出现问题时，解决的难度也相对较大。
目前LVS和LDirectd 也支持对服务器内部情况的监控，但不能重新发送请求。
比如用户正在上传一个文件，而处理该上传信息的节点刚好出现故障，则Nginx会把上传请求重新发送到另一台服务器，而LVS在这种情况下会直接断掉。
Nginx还能支持HTTP和Email（Email功能很少有人使用），LVS所支持的应用在这个电商比Nginx更多。
4-Nginx同样能承受很高负载并且能稳定运行，由于处理流量受限于机器I/O等配置，所以负载能力相对较差。
5-Nginx 安装、配置及测试相对来说比较简单，因为有相应的错误日志进行提示。
6-Nginx本身没有现成的热备方案，所以在单机上运行风险较大，建议KeepAlived配合使用
Nginx可以作为LVS的节点机器使用，充分利用Nginx的功能和性能。当然这种情况也可以直接使用Squid等其他具备分发功能的软件。
使用环境对比
具体应用具体分析。如果是比较小型的网站（每日PV小于100万），用户Nginx就完全可以应对，如果机器也不少，可以用DNS轮询。
LVS后用的机器较多，在构建大型网站或者提供重要服务且机器较多时，可多加考虑利用LVS。
概念类
nginx
Nginx("engine x") 是一个高性能的HTTP和反向代理服务器，也是一个IMCP/POP3/SMTP服务器。
用途
Nginx作为负载均衡服务器：既可以在内部直接支持Rails和PHP程序对外进行服务，也可以支持作为HTTP代理服务器对外进行服务；
Nginx作为邮件代理服务器。
优势
1．Nginx专为性能优化而开发，实现上非常注重效率。它支持内核Poll模型，能经受高负载的考验,有报告表明能支持高达 5w个并发连接数。
2．Nginx具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。
Nginx采取了分阶段资源分配技术，使得它的CPU与内存占用率非常低。
3．Nginx支持热部署。它的启动特别容易,并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下，对软件版本进行升级。
4．Nginx采用master-slave模型,能够充分利用SMP(对称多处理)的优势，且能够减少工作进程在磁盘I/O的阻塞延迟。当采用select()/poll()调用时，还可以限制每个进程的连接数。
5．Nginx代码质量非常高，代码规范，手法成熟，模块扩展也很容易。
6．Nginx采用了一些OS提供的最新特性如，从而大大提高了性能。
概念类
LVS
LVS是Linux Virtual Server的简写，即Linux虚拟服务器，是一个虚拟的服务器集群系统。宗旨是使用集群技术和Linux操作系统实现一个高性能、高可用的服务器。
LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度起自动屏蔽服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
集群的三层结构：
负载调度器
整个集群对外面的前端机，负责将客户的请求发送到一组服务器执行，而客户认为服务来自一个IP地址（虚拟IP地址）上的。
采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。
服务器池
是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。
共享存储
它为服务器池提供一个共享的存储区，容易使得服务服务器拥有相同的内容。提供相同的服务
共享存储通常是数据库、网络文件系统、分布式文件系统。
分布式锁管理器：
当不同服务器上的应用程序同事读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态，这就需要分布式锁管理器。
监视器(Graphic Monitor)：
Graphic Monitor是为系统管理员提供整个集群系统的监视器，它可以监视系统的状态。
Graphic Monitor是基于浏览器的，所以无论管理员在本地还是异地都可以监测系统的状况。
LVS三种负载均衡：
VS/NAT
VS/NAT是一种最简单的方式，所有的服务器只需要将自己的网关指向Director即可。
优势：服务器可以运行任何支持TCP/IP的操作系统，只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。
缺点：伸缩能力有限，调度器本身可能称为系统的新瓶颈。
VS/TUN
调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中
再将封装后的IP报文转发给选出的服务器;
服务器收到报文后，先将报文解封获得原来目标地址为 VIP 的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。
优势：负载调度器枝江请求调度到不同的后端服务器，后端服务器将应答直接返回给用户，极大地增加负载调度器调度的服务器数量
VS/DR
VS/DR方式是通过改写请求报文中的MAC地址部分来实现的。
调度器和服务器必需在物理上有一个网卡通过不间断的局域网相连。
在VS/DR中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。
调度器的VIP地址对外可见，而服务器的VIP对外是不可见的。
优势：同VS/TUN方法一样，提高了LVS集群系统的伸缩性。这种方法没有IP隧道的开销，效率最高。但是要求负载调度器与服务器都有一块网卡连在同一物理网段上，服务器网络设备不做ARP响应。
分布式文件系统：
1.分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。
2.分布式文件系统的设计基于客户机/服务器模式。
3.分布式文件系统可以有效解决数据的存储和管理难题：将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，众多的节点组成一个文件系统网络。
系统分类：
NFS（网络文件系统)
NFS的实质在于用户间计算机的共享。用户可以联结到共享计算机并像访问本地硬盘一样访问共享计算机上的文件。
Andrew系统
通过基于单元的结构生成一种可管理的分布式环境。一个单元是某个独立区域中文件服务器和客户机系统的集合，这个独立区域由特定的机构管理。
KASS系统
基于JAVA的纯分布式文件系统，功能类似于DFS、GFS、Hadoop，通过HTTP WEB为企业的各种信息系统提供底层文件存储及访问服务，搭建企业私有云存储服务平台。
无状态系统NFS和回呼系统AFS区别：
无状态系统
服务器并不保存其客户机正在缓存的文件的信息。因此，客户机必须协同服务器定期检查是否有其他客户改变了自己正在缓存的文件。
回呼系统
服务器记录它的那些客户机的所作所为，并保留它们正在缓存的文件信息。服务器在一个客户机改变了一个文件时使用应答技术通知其它客户机。
lvs的优势：
1.抗负载能力强，因为lvs工作方式的逻辑是非常简单的，而且工作再网络层第4层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。lvs一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU等）出现问题导致lvs出现问题。
2.配置性低，这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3.工作稳定，因为其本省抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体式非常稳定的。
4.无流量，lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5.lvs基本上能支持所有应用，因为绿色工作在第4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。
另外：lvs也不是完全能判别节点故障的，比如在wlc分配方式下，集群里有一个节点没有配置vip，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机器。目前这个问题还在进一步测试中。所以用lvs也得多多当心为妙。
nginx和lvs作对比的结果：
1.nginx工作在网络的第7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以nginx单凭这点可以利用的场合就远多于lvs了
但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点来看，触碰多了，人为出现问题的几率也就会大。
2.nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；
lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。
另外注意，lvs需要向托管商至少申请多于一个ip来做visual ip，貌似是不能用本省的ip来做VIP的。
3.nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。
lvs的安装和配置、测试就要花比较长的时间，因为同上所述，lvs对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多。
4.nginx也同样能承受很高负载且稳定，但负载度很稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；
本身的bug也还是难以避免的；
nginx没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说。
5.nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。
目前lvs中ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6.nginx对请求的异步处理可以帮助节点服务器减轻负载，键入使用Apache直接对外服务，那么出现很多的窄带链接(解释)时Apache服务器将会占用大量内存而不能释放，使用多于一个nginx做Apache代理的话，这些窄带链接会被nginx挡住，Apache上就不会堆积过多的请求，这样就减少了相当多的内存占用。
这点使用squid也有相同的作用，即使squid本身配置为不缓存，对Apache还是有很大帮助你的。lvs没有这些功能，也就无法能比较。
7.nginx能支持http和Email（Email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更过。
在使用上，一般最前端所采取的的策略应是lvs，也就是dns的指向应为lvs均衡器，lvs的优点另它非常适合做这个任务。
重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而来。
所以将这些重要ip交给lvs托管式最为稳妥的，这样做的唯一缺点是需要VIP数量会比较多。
nginx可以作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少，性能上也有所逊色于nginx。
nginx也可以作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的ip也是重要的，所以中层代理业拥有一个VIP和lvs是最完美的方案了。
nginx也可以作为网页静态服务器。
扩展1
使用nginx+keepalived实现负载均衡，解决单点与高流量并发问题。为什么要用nginx而不用lvs？
7个理由：
1.高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2——3万并发连接数。
2.内存消耗少：在3万并发连接数下，开启的10个nginx进程才消耗150M内存（150*10=150M）。
3.配置文件非常简单：风格跟程序一样通俗易懂。
4.成本低廉：nginx为开源软件，可以免费使用。而购买F5 big-ip、netscaler等硬件负载均衡交换机则需要十多万至几十万人民币。
（使用nginx做七层负载均衡的理由？）
5.支持rewrite重写规则：能够根据域名、url的不同，将http请求分到不同的后端服务器群组。
6.内置的健康检查功能：如果nginx proxy后端的某台web服务器宕机了，不会影响前端访问。
7.节省带宽：支持gzip压缩，可以添加浏览器本地缓存的header头。
扩展2
keepalived是linux下面实现vrrp备份路由的高可靠性运行件。基于keepalived设计的服务模式能够真正做到主服务器和备份服务器故障时ip瞬间无缝交接。
nginx是基于linux2.6内核中epoll模型http服务器，与Apache进程派生模式不同的是nginx进程基于master+slave多进程模型，自身具有非常稳定的子进程管理功能。
在master进程分配模式下，master进程永远不进行业务处理，只是进行任务分发，从而达到master进程的存活高可靠性，slave进程所有的业务信号都由主进程发出，slave进城所有的超时任务都会被master终止，属于阻塞式人物模型。
服务器ip存活检测是由keepalived自己本身完成的，将2台服务器配置成keepalived互为主辅关系，任意一方机器故障对方都能够将ip接管过去。
keepalived的服务器ip通过其配置文件进行管理，依靠其自身的进程去确定服务器的存活状态，如果在需要对服务器进程在线维护的情况下，只需要停掉被维护机器的keepalived服务进程，另外一台服务器就能够接管该台服务器的所有应用。
nginx 常用模块
.HttpProxyModule：
•功能：允许 Nginx 充当反向代理服务器，将客户端请求转发到后端的多个服务器上。
•使用方法：在 Nginx 配置文件中使用 proxy_pass 指令指定后端服务器的地址和端口。可以配置负载均衡、缓存、SSL/TLS 加密等选项。
2.HttpRewriteModule：
•功能：用于 URL 重写和重定向，修改请求的 URI 或将请求重定向到其他 URL 地址。
•使用方法：使用 rewrite 指令在 Nginx 配置文件中指定规则。可以根据正则表达式匹配请求的路径，并进行相应的重写或重定向操作。
3.HttpSSLModule：
•功能：支持 SSL/TLS 加密功能，使 Nginx 能够处理加密连接。
•使用方法：配置 SSL 证书、密码套件、协议版本等参数。在 Nginx 配置文件中使用 listen 指令设置监听端口为 HTTPS，并指定 SSL 相关配置。
4.HttpGzipModule：
•功能：对响应进行压缩，减小传输的数据量，提高性能。
•使用方法：使用 gzip 指令在 Nginx 配置文件中启用 gzip 压缩。可以配置压缩级别、压缩类型等参数。
5.HttpCacheModule：
•功能：实现 HTTP 缓存，减少后续相同请求的响应时间。
•使用方法：使用 proxy_cache_path 指令指定缓存路径，在需要缓存的地方使用 proxy_cache 指令启用缓存。可以配置缓存的有效性判断条件、存储策略等选项。
6.HttpAccessModule：
•功能：用于访问控制，限制对指定资源的访问。
•使用方法：使用 allow 和 deny 指令在 Nginx 配置文件中指定允许或拒绝访问的主机、IP 地址、用户等。可以根据需要设置多个规则。
7.HttpUpstreamModule
•功能：Nginx的负载均衡模块，用来对后台服务器的任务调度及分配，分配原则可以通过算法进行控制。
•使用方法：一般和http_proxy模块一起使用，常见模式：Nginx+Apache, Nginx+Tomcat
这些模块是 Nginx 提供的常用模块之一，每个模块都有自己的特定功能和使用方法。你可以根据具体需求，在 Nginx 配置文件中进行相应的配置。
lb1
因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取