Nginx 简介
Nginx (“engine x”) 是一个高性能的HTTP和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。
Nginx是一款轻量级的Web 服务器/ 反向代理 服务器及电子邮件(IMAP/POP3)代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler(俄文:Рамблер)使用。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有:淘宝、百度、新浪、 网易 、 腾讯 等。
nginx应用场景
1、http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。
2、虚拟主机。可以实现在一台服务器虚拟出多个网站，例如个人网站使用的虚拟机。
3、反向代理， 负载均衡 。当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用nginx做反向代理。并且堕胎服务器可以平均分担负载，不会应为某台服务器负载高宕机而某台服务器闲置的情况。
nginx的主要特点
- 高并发连接: 官方称单节点支持5万并发连接数，实际生产环境能够承受2-3万并发。
- 内存消耗少: 在3万并发连接下，开启10个nginx进程仅消耗150M内存 (15M*10=150M)
- 配置简单
- 成本低廉: 开源免费
- 支持rewrite重写规则: 能够根据域名、url的不同，将http请求分发到后端不同的应用服务器节点上
- 内置健康检查功能: 如果后端的某台应用节点挂了，请求不会再转发给这个节点，不影响线上功能
- 节省带宽: 支持gzip压缩
- 反向代理: 支持分布式部署环境，消除单点故障，支持7 * 24小时不停机发布
Nginx 学习系列 ————- 负载均衡
说到负载均衡，我想说它天生就是不公平的。为什么这么说呢？请你想象这么一个场景，一块蛋糕切成5份，现在要将它分给A、B、C3个人，基于公平原则，我们说每个人正常可以分到5/3份，但是，5/3份很明显不好进行划分，诶碰巧这个时候A中午没有吃饭，能多吃几份，B、C肚子偏饱，1份即可，基于不公平原则，我们分给A3份蛋糕，B、C个一份，这样按照一定策略将资源进行划分的方式，是一种均衡的策略。
在web应用中，一个web应用（或者说某个服务）在生产环境中一般是集群部署，然后采用负载均衡硬件(F5)或者软件（nginx）将请求分发到不同的服务主机中进行处理，很明显，这里的蛋糕就相当于我们的web request ，假设有5个request进来，基于一定的均衡策略，我们可能会将其中的3个request交给A服务器去处理，B、C服务器各处理1个request。下面我画张图片简单说明这个模型：
那么使用负载均衡有什么好处呢？首先优化资源利用率，最大化吞吐量，减少延迟，再者系统的伸缩性和可靠性也得到了相应的保障。
一、Nginx 负载均衡及相关策略介绍
负载均衡技术少不了相关的均衡策略，Nginx 中提供了 4 种均衡策略，我们可以根据具体的业务场景选择合适的均衡策略。下面分别介绍这 4 中均衡策略：
- 1、基于 轮询 的均衡策略：
- 轮询嘛，就是说对进到nginx的request按照遍历的方式进行分发，如果request 1 分发到 Server A，那么request 2将被分发到 Server B,……以此循环类推
- 2、基于最少连接数的均衡策略：
- 最少连接，也就是说nginx会判断后端集群服务器中哪个Server当前的 Active Connection 数是最少的，那么对于每个新进来的request,nginx将该request分发给对应的Server.
- 3、基于ip-hash的均衡策略：
- 我们都知道，每个请求的客户端都有相应的ip地址，该均衡策略中，nginx将会根据相应的hash函数，对每个请求的ip作为关键字，得到的hash值将会决定将请求分发给相应Server进行处理
- 4、基于加权轮询的均衡策略：
- 加权轮询，很显然这个策略跟我们开题引入的场景是一样的，nginx会给Server配置相应的权重，权重越大，接收的request数将会越多
上面的均衡策略其实都非常很好理解，但是如果想了解其实现原理，可以看源代码，但是小编就算了，我是看不懂C、C++的。
二、Nginx 不同均衡策略的配置介绍
- 1、基于轮询的均衡策略：
这个是Nginx默认的均衡算法，如果你不进行相关的配置，默认会执行该策略，配置如下：
复制代码
可以看出，nginx负载均衡使用到的指令不多，其中比较重要的两个是upstream和proxy_pass,upstream块定义一个后端小集群，里边配置相关的Server组成这个集群，同时upstream为这个集群起个相应的名字，本实例叫myapp1.proxy_pass处于location块中，表示对于所有符合/的request，将会交给哪个集群进行处理，本实例为。
但又一点我们需要注意，上面中myapp1必须是upstream起的名字，对于协议是使用http还是 https ,都无所谓，如果你的协议使用https，则将http直接改成https即可。另外，如果你在upstream中的server指令中指定了协议名，那么在proxy_pass指令中就不需要加上协议名称了。
nginx负载均衡使用反向代理实现，也就是我们上面使用到的proxy_pass指令，支持的协议不止是http和https,同时还支持FastCGI、uwsgi、SCGI、memcached、gRPC，如果你需要使用除了http、https外的其他协议，我们不能使用proxy_pass指令了，应该转而使用相应的指令，如fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_pass。
该策略处理负载，小编认为还是有缺陷的，不能防止某台Server出现负载过高的情况。因为如果有些请求执行时间过长，而系统的并发量却非常大，那么就可能导致某台Server出现request堆积，负载过高，snowslide is possible~
- 2、基于最少连接数的均衡策略：
该策略主要使用了least_conn指令，具体配置如下：
upstream myapp1 {
least_conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
复制代码
该策略还是比较人性化的，可以按照机器的实际情况进行刚需分配。
- 3、基于ip-hash的均衡策略：
当然了，如果我们想实现这样一个功能，我们想让对于相同客户端的请求每次都被分发到同一个Server进行处理，上面两种策略都是不做到。此策略可确保来自同一客户端的请求始终定向到同一服务器，但此服务器不可用时除外。相关配置如下：
upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
复制代码
既然相同客户端的请求能被同一台Server进行处理，那么相同客户端的会话 Session 就可以实现持久化了。
- 4、基于加权轮询的均衡策略：
基于加权轮询的策略就不需要过多讲解了，就是在轮询的基础上加上个权重信息
upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
server srv3.example.com;
}
复制代码
这种策略适合Server机器处理能力有区别的情况。
三、nginx 负载均衡更多高级特性及配置
- 1、健康检查
- 不仅人需要体检，机器也是需要体检的，那么就当nginx就是那位体检医生吧！nginx健康检查是什么呢？当我们一个request进来被分发到相应的Server进行处理后，nginx会检查该request执行是否超时，是否执行失败了等情况，然后做出相应的处理—比如说当nginx检查出Server A执行某request时报出502错误了，那么下次nginx负载均衡时就会在upstream块中将Server A排除掉，不分发请求给到Server A了。
- 对于健康检查的功能，nginx提供了基本两个指令，即max_fails和fail_timeout,也就是说当nginx检查到某Server发生错误的request数达到max_fails或者执行某request执行时间超过fail_timeout了，如果发生超时了，nginx将开始使用实时请求优雅地探测Server，如果有响应，则认为对应的Server还是活着的，没有毛病的。
- 2、更多配置
- 针对上面upstream块中的server指令，其格式为：server address [ parameters ];，里边的parameters可以有很多的参数类型，比如说指定某台Server不参与负载均衡等。具体配置详见官网链接，点击此处传送门。
