4.负载均衡策略在nginx中支持的负载均衡策略如下： 轮询加权策略（Round-Robin）：在轮询模策略中，要求应用服务器是分布式的 最少连接策略（Least-Connected）：下一个请求是分配给最少的活动连接数服务器。 IP哈希策略（IP-Hash）：一个哈希函数用来决定那个服务器被选择作为下一个请求处理的服务器（基于客户端的IP地址）。 4.1.轮询策略
http { upstream myapp1 { #服务器组，组名：myapp1 server srv1.example.com; #web应用服务器1 server srv2.example.com; #web应用服务器2 server srv3.example.com; #web应用服务器3 }
server { listen 80;
location / { proxy_pass http://myapp1; #客户端访问的URL } } } 以上是最简单的Nginx负载均衡配置。在upstream myapp1中有3个应用服务器实例，当负载均衡中没有指定配置负载策略时，默认是使用轮询权重策略。所有请求都是代理给服务器组myapp1，Nginx应用http负载均衡到分布式请求中。 在Nginx反向代理负载均衡的扩展包括：http，https，FastCGI，uwsgi，SCGI和缓存。 配置负载均衡 配置https负载均衡代替http，只使用“https”作为协议就可以了。 当设置负载均衡为FastCGI，uwsgi，SCGI，或缓存，指令分别使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。 如果可以把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器；第二，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成初始状态，以避免造成所有的机器都处在timeout的状态，从而导致整个前端被夯住。 4.2.最少连接策略upstream myapp1 { #服务器组，组名：myapp1 least_conn; #least_conn;最少连接策略 server srv1.example.com; #web应用服务器1 server srv2.example.com; #web应用服务器2 server srv3.example.com; #web应用服务器3 } 最少连接允许控制加载应用实例，更多适合在一些花费比较长时间去完成请求的一个场景中。 用最少连接负载均衡，Nginx会尽量不要求过载繁忙的应用服务器去执行请求，分配新的请求给一个不太忙碌的服务器代替执行。 最少连接负载均衡在Nginx中被激活时，least_conn指令被用来作为服务器群组配置的一个部分。 4.3.IP哈希策略配置IP哈希负载均衡，只需要添加ip_hash指令指向服务器(uptream) 组配置： upstream myapp1 { ip_hash; server srv1.example.com; server srv2.example.com; server srv3.example.com; } 每个客户端请求都有可能发送到不同的服务器，不能保证同一个客户端总是指向同一个服务器。如果一个客户端必须要跟服务器的会话关联在一起的时候，可以使用IP哈希负载均衡缓存策略。 通过获取客户端额IP地址，经过哈希函数的计算得到一个值，利用该值对服务器的列表大小进行取模运算，得到的值就是处理客户端请求的服务器序号。采用IP哈希负载均衡策略，的优点是，同一个客户端的IP地址，每次发送的请求都是指向同一台服务器进行处理。这种方式确保来自同一个客户端请求总是指向同一个服务器除非这个服务是无效的。 举例子说明： 例如一个系统的会话存储用户信息，每次将请求发送到服务器，服务器都会从会话中获取数据。但在负载均衡环境中，每次客户端的每次请求都可能由不同的服务器处理，所以可能出现无法获取的到客户端的会话数据（由于会话数据是保存在服务器的内存中）。 4.4.权重策略使用服务器权重策略，它也有可能影响到Nginx负载均衡算法。 在上面的例子中，服务器权重没有配置，意味着所有指定的服务器都被视为同等资格的一个特定负载均衡策略。尤其是轮询策略，它也意味着差不多平等地分配请求给服务器，并且快速平均地处理请求。
当权重参数被指定在一个服务器时，权重作为负载均衡决策的部分。 upstream myapp1 { server srv1.example.com weight=3; server srv2.example.com; server srv3.example.com; } 在这个配置中，每5个请求都分配给应用服务器实例如下： 3个请求将分配到serv1中，1个请求分配给srv2中，而另外1个请求则分配个srv3中。 在最近的Nginx版本中，它同样可以与最少连接和IP哈希策略一样去使用权重策略。 4.5.总结轮询策略： 优点：如果希望每个服务器都能平均处理客户端请求可使用轮询策略。 缺点：不支持会话管理，另外，假设有5个客户端请求，有2台服务器处理请求，某一台服务器处理请求时消耗资源比较大，每次都接到消耗资源比较大的请求，那么该服务器处理能力就会下降。
IP哈希策略： 缺点：使用该策略，服务器可能不会平均处理每个请求。假设有5个客户端请求，那么通过计算出哈希值后，可能都是由一台服务器处理。其它的服务器可能没有请求需要处理。 优点：支持会话管理，如果系统中使用会话处理数据，该策略比较适合。
最少连接策略： 优点：系统把新连接分配给当前连接数目最少的服务器。该算法在各个服务器运算能力基本相似的环境中非常有效。此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。 缺点：虽然某个服务器的连接数较少，但处理请求时间较长，这时候再接受请求处理，可能影响到时间效率的问题。
权重策略： 优点：如果服务器的硬件等级差别比较大，那么配置高的服务器可分配较高权重，以便处理更多的请求。而配置低的服务器可接受少量请求。 缺点：如果服务器的硬件等级一样不太适合使用该策略。5.健康检查在Nginx反向代理中实现主动或被动健康检查，如果指定的响应服务器出现错误，Nginx将标记该服务器为失败，将尽量去避免为后续的请求选择该服务器。 设置发生在超时失败期间连续不成功的服务器通信的max_fails指令。默认max_fails设置是1，当设置为0次时，这台服务器的检查检查不启用。Fail_timeout参数定义服务器多长时间将被标记为失败。在服务器fail_timeout期间，Nginx不会马上将该服务器标记为失败的服务器，而是模拟想客户端请求去侦查服务器，如果侦查成功，该服务器标记为在线服务器。 关于健康检查的的插件需要花钱购买，更多的信息请参考： https://www.nginx.com/products/application-health-checks/ https://www.nginx.com/resources/admin-guide/installing-nginx-plus/ 6.附录6.1.systemctl命令指南Systemctl是一个systemd工具，主要负责控制systemd系统和服务管理器。 Systemd是一个系统管理守护进程、工具和库的集合，用于取代System V初始进程。Systemd的功能是用于集中管理和配置类UNIX系统。 在Linux生态系统中，Systemd被部署到了大多数的标准Linux发行版中，只有为数不多的几个发行版尚未部署。Systemd通常是所有其它守护进程的父进程， 但并非总是如此。使用Systemctl管理Linux服务 6.1.1.Systemd初体验和Systemctl基础6.1.1.1.1.检查systemd安装版本1. 首先检查你的系统中是否安装有systemd并确定当前安装的版本 # systemd –version
6.1.1.1.2.检查systemd和systemctl的二进制文件和库文件的安装位置 # whereis system
# whereis systemctl |
