系统架构nginx调优(nginx调度)

nginx调度

要解决高并发问题，先要了解负载均衡。什么是负载均衡？

当一台服务器的性能达到极限时，我们可以使用服务器集群来提高网站的整体性能。那么，在服务器集群中，需要有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台后端服务器去处理。

那么在这个过程中，调度者如何合理分配任务，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡问题。

下面详细介绍负载均衡的五种实现方式

（一）HTTP重定向实现负载均衡

过程描述

当用户向服务器发起请求时，请求首先被集群调度者截获；调度者根据某种分配策略，选择一台服务器，并将选中的服务器的IP地址封装在HTTP响应消息头部的Location字段中，并将响应消息的状态码设为302，最后将这个响应消息返回给浏览器。

当浏览器收到响应消息后，解析Location字段，并向该URL发起请求，然后指定的服务器处理该用户的请求，最后将结果返回给用户。

在使用HTTP重定向来实现服务器集群负载均衡的过程中，需要一台服务器作为请求调度者。用户的一项操作需要发起两次HTTP请求，一次向调度服务器发送请求，获取后端服务器的IP，第二次向后端服务器发送请求，获取处理结果。

调度策略

随机分配策略

当调度服务器收到用户请求后，可以随机决定使用哪台后端服务器，然后将该服务器的IP封装在HTTP响应消息的Location属性中，返回给浏览器即可。

轮询策略(RR)

调度服务器需要维护一个值，用于记录上次分配的后端服务器的IP。那么当新的请求到来时，调度者将请求依次分配给下一台服务器。

由于轮询策略需要调度者维护一个值用于记录上次分配的服务器IP，因此需要额外的开销；此外，由于这个值属于互斥资源，那么当多个请求同时到来时，为了避免线程的安全问题，因此需要锁定互斥资源，从而降低了性能。而随机分配策略不需要维护额外的值，也就不存在线程安全问题，因此性能比轮询要高。

优缺点分析

采用HTTP重定向来实现服务器集群的负载均衡实现起来较为容易，逻辑比较简单，但缺点也较为明显。

在HTTP重定向方法中，调度服务器只在客户端第一次向网站发起请求的时候起作用。当调度服务器向浏览器返回响应信息后，客户端此后的操作都基于新的URL进行的(也就是后端服务器)，此后浏览器就不会与调度服务器产生关系，进而会产生如下几个问题：

由于不同用户的访问时间、访问页面深度有所不同，从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时，无法知道当前用户将会对服务器造成多大的压力，因此这种方式无法实现真正意义上的负载均衡，只不过是把请求次数平均分配给每台服务器罢了。

若分配给该用户的后端服务器出现故障，并且如果页面被浏览器缓存，那么当用户再次访问网站时，请求都会发给出现故障的服务器，从而导致访问失败。

（二）DNS负载均衡

首先需要将我们的域名指向多个后端服务器(将一个域名解析到多个IP上)，再设置一下调度策略，那么我们的准备工作就完成了，接下来的负载均衡就完全由DNS服务器来实现。

当用户向我们的域名发起请求时，DNS服务器会自动地根据我们事先设定好的调度策略选一个合适的IP返回给用户，用户再向该IP发起请求。

调度策略

一般DNS提供商会提供一些调度策略供我们选择，如随机分配、轮询、根据请求者的地域分配离他最近的服务器。

优缺点分析

DNS负载均衡最大的优点就是配置简单。服务器集群的调度工作完全由DNS服务器承担，那么我们就可以把精力放在后端服务器上，保证他们的稳定性与吞吐量。而且完全不用担心DNS服务器的性能，即便是使用了轮询策略，它的吞吐率依然卓越。此外，DNS负载均衡具有较强了扩展性，你完全可以为一个域名解析较多的IP，而且不用担心性能问题。

但是，由于把集群调度权交给了DNS服务器，从而我们没办法随心所欲地控制调度者，没办法定制调度策略。

DNS服务器也没办法了解每台服务器的负载情况，因此没办法实现真正意义上的负载均衡。它和HTTP重定向一样，只不过把所有请求平均分配给后端服务器罢了。

此外，当我们发现某一台后端服务器发生故障时，即使我们立即将该服务器从域名解析中去除，但由于DNS服务器会有缓存，该IP仍然会在DNS中保留一段时间，那么就会导致一部分用户无法正常访问网站。这是一个致命的问题！好在这个问题可以用动态DNS来解决。

动态DNS

动态DNS能够让我们通过程序动态修改DNS服务器中的域名解析。从而当我们的监控程序发现某台服务器挂了之后，能立即通知DNS将其删掉。

综上所述

DNS负载均衡是一种粗犷的负载均衡方法，这里只做介绍，不推荐使用。

（三）反向代理负载均衡（nginx+uwsgi）

什么是正向代理，正向代理是内网通过代理访问外网，这个代理就是正向代理。而反向代理是指，外网通过代理访问内网，那这个代理就是反向代理。

假设把你公司的网看成是内网，那么你从公司里面的一台电脑上访问你家里的电脑上的服务，那就的通过正向代理，而你从你家电脑访问公司的这台电脑，就要通过反向代理。

使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服务器将请求 均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web 服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。

反向代理处于web服务器这边，反向代理服务器提供负载均衡的功能，同时管理一组web服务器，它根据负载均衡算法将请求的浏览器访问转发到不同的web服务器处理，处理结果经过反向服务器返回给浏览器。

优点：

隐藏后端服务器。

与HTTP重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接交互，从而能够确保调度者的控制权，提升集群的整体性能。

故障转移

与DNS负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时，能够及时通知反向代理服务器，并立即将其删除。

合理分配任务

HTTP重定向和DNS负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。

缺点：

调度者压力过大

由于所有的请求都先由反向代理服务器处理，那么当请求量超过调度服务器的最大负载时，调度服务器的吞吐率降低会直接降低集群的整体性能。

制约扩展

当后端服务器也无法满足巨大的吞吐量时，就需要增加后端服务器的数量，可没办法无限量地增加，因为会受到调度服务器的最大吞吐量的制约。

（四）IP负载均衡

原理：在网络层通过修改目标地址进行负载均衡。

用户访问请求到达负载均衡服务器，负载均衡服务器在操作系统内核进程获取网络数据包，根据算法得到一台真实服务器地址，然后将用户请求的目标地址修改成该真实服务器地址，数据处理完后返回给负载均衡服务器，负载均衡服务器收到响应后将自身的地址修改成原用户访问地址后再讲数据返回回去。类似于反向服务器负载均衡。

优点：在响应请求时速度较反向服务器负载均衡要快。

缺点：当请求数据较大（大型视频或文件）时，速度较慢。

（五）数据链路层负载均衡

原理：在数据链路层修改Mac地址进行负载均衡。

负载均衡服务器的IP和它所管理的web 服务群的虚拟IP一致；

负载均衡数据分发过程中不修改访问地址的IP地址，而是修改Mac地址；

通过这两点达到不修改数据包的原地址和目标地址就可以进行正常的访问。

优点：不需要负载均衡服务器进行地址的转换。数据响应时不需要经过负载均衡服务器。

缺点：负载均衡服务器的网卡带宽要求较高。

nginx调优

     wgcloud非常的简单，你不用写各种模板和脚本，安装完成后就自动监控了，安装在网站有详细的说明。

     系统模块如下：

     1.主机集群监控，默认配置可支持500+主机同时在线监控，再多点也可以。如果做一些调优和加强，可支持数千节点监控。

     2.CPU监控，内存监控，系统负载，磁盘等基础指标监控，这些都是必备的，不用说了哈，cpu，内存，磁盘都支持告警。

     3.数据监控(mysql，oracle，pg等)，这个是做什么的呢，比如你想监控每个小时有多少订单产生，有多少注册用户，这个功能就很有用了，它支持你写sql来统计数据，监控数据的变化趋势，当然不能写敏感字啊，系统做了很完善的过滤机制了，不用担心。数据源连接不成功时候会告警。

     4.服务心跳检测，这个就是服务接口的健康检测，看你能返回200不，否则就算失败，支持告警。

     5.进程监控，支持pid文件，进程id，进程名称来监控进程是否正常运行，使用了多少内存和cpu，支持告警。

     6.docker监控，监控docker的使用状态，支持告警。

     7.磁盘监控，监控磁盘的使用情况。

     8.网络拓扑图，自动生成server和所有主机的网络拓扑图，很漂亮。

     9.端口监控，监控端口是否telnet通，这个排除了网络防火墙因素，相当于telnet localhost 端口，支持告警。

     10.日志文件监控，可以监控日志里有无关键字，有就告警，可以指定具体的日志文件或日志所在的目录，如/usr/local/nginx/logs/access.log，或/usr/local/nginx/logs/，指定目录时候会读取目录下最新的日志文件

     11.告警方式，默认是邮件，也支持告警脚本执行，可以在脚本里实现钉钉微信等方式来告警，所有指标告警都可以在配置文件里关闭和开启。

     12.设备管理，这个很有用哈，可以用来管理公司的各种设备。

     13.主机画像，这个是对主机的cpu，内存，磁盘，负载，监控的端口，进程，docker，日志文件等所有信息进行全部展示。

nginx调用脚本

CGI（Common Gateway Interface，通用网关接口）

nginx cgi是一种通用网关接口规范，该规范详细描述了 Web 服务器和请求处理程序（脚本解析器）在获取及返回数据过程中传输数据的标准，如 HTTP 协议的参数名称等。大多数 Web 程序以脚本形式接收并处理请求，然后返回响应数据，如脚本程序 PHP、JSP、Python 等。

nginx性能调整

       Nginx是一款常用的高性能Web服务器，其配置文件主要由模块指令和上下文组成，可以通过配置文件实现反向代理、负载均衡、缓存等功能。下面是nginx配置的一些详解：

1.server：server指令用于配置虚拟主机，可以在一个Nginx服务器中配置多个虚拟主机，每个虚拟主机有自己的配置。

2.location：location指令用于配置URL的匹配规则，可以匹配URI、文件扩展名等，可以通过配置不同的location实现反向代理和缓存等功能。

3.upstream：upstream指令用于配置反向代理的后端服务器，可以配置多个服务器进行负载均衡，支持不同的负载均衡算法。

4.proxy_pass：proxy_pass指令用于配置反向代理的转发规则，可以将请求转发到指定的后端服务器。

5.cache：cache指令用于配置缓存规则，可以通过配置缓存来提高Web服务器的性能。

6.ssl：ssl指令用于配置SSL协议，可以实现HTTPS的安全通信。

       除了以上指令外，还有许多其他的Nginx指令，例如gzip、log_format、rewrite等，可以根据具体需求进行配置。总的来说，Nginx的配置相对简单，但具有很高的灵活性和可扩展性，可以根据不同的场景进行灵活配置。

nginx调度配置

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

调度算法

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

动态方法：根据算法及后端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。

简单算法：active*256+inactive (谁的小，挑谁)

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

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

简单算法：（active*256+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地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。