nginx负载均衡简介

1. Nginx内核与模块划分

1.1 内核

其设计非常微小和简洁，完成的工作也非常简单。仅通过查找配置文件将客户端请求映射到一个location block（location是nginx配置中的一个指令，用例URL匹配），而在这个location中所配置的每个指令将会启动不同的模块取完成相应的工作。

1.2 从结构上划分

1. 核心模块：HTTP模块、EVENT模块和MAIL模块。
2. 基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块。
3. 第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

1.3 从功能上划分

1. Core(核心模块)：构建nginx基础服务、管理其他模块。
2. Handlers（处理器模块）：此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
3. Filters （过滤器模块）：此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
4. Proxies （代理类模块）：此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。

2. Nginx模块处理流程

模块处理流程大致如下：

1. 收到HTTP请求。
2. Nginx基于配置文件中的位置选择一个合适的处理模块（Handlers）。
3. Handlers模块需要把请求反向代理到后端服务器，就需要就变成另外一类的模块：load-balancers（负载均衡模块）。
4. 负载均衡模块的配置中有一组后端服务器，当一个HTTP请求过来时，它决定哪台服务器应当获得这个请求。
5. 处理完成后，filters（过滤模块）将被调用。每个请求都可以被压缩成块，依次经过多个filters（过滤模块）过。它们的执行顺序在编译时决定。过滤模块链以流水线的方式高效率地向客户端发送响应信息。每个filters（过滤模块）不会等上一个filters（过滤模块）全部完成，就像是流水线一样。
6. 最后把响应发给客户端。

如下图，展示了Nginx模块常规的HTTP请求和响应过程：

Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。

通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。

3. Nginx负载均衡算法

目前nginx提供3种自带的负载均衡，还有2种常用的第三方策略。

1. 安装轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低，但缺点是：可靠性低和负载分配不均衡。
2. 权重：指定轮询几率，weight和访问比例成正比，用于后端服务器性能不均的情况。如下图，8080和8081分别占90%和10%。
   
3. ip_hash：上面2种方式都有一个问题，就是下一个请求来的时候，请求可能分发到另外一个服务器，当我们的程序不是无状态的时候（采用session保存数据），这个时候，就有一个很大的问题，比如把登录信息保存到了session中，那么跳转到另外一个服务器的时候就需要重新登录了，所以很多时候，我们只需要一个客户只访问一个服务器，那么就需要用到iphash。iphash的每个请求按访问ip的hash结果分配，这个每个访客访问一个后端服务器，可以解决session问题。
   
4. fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。
5. url_hash（第三方）：按访问URL的hash结果进行分配请求，使每个URL定向到同一个后端服务器，后端服务器为缓存时比较有效。在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用hash算法。

4. Nginx处理请求

Nginx在启动时会以daemon形式在后台运行，采用多进程+异步非阻塞IO事件模型来处理各种连接请求。

4.1 多进程模型

多进程模型包括一个master进程，多个worker进程，一般worker进程个数是根据服务器CPU核数来决定的。master进程负责管理Nginx本身和其他worker进程。

从上图中可以很明显地看到，4个worker进程的父进程都是master进程，表明worker进程都是从父进程fork出来的，并且父进程的ppid为1，表示其为daemon进程。

4.2 Master进程的作用

读取并验证配置文件nginx.conf；管理worker进程，包括：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

4.3 Worker进程的作用

处理基本的网络事件，在nginx多进程中，每个worker都是平等的，因此每个进程处理外部请求的机会权重都是一致的。

每一个Worker进程都维护一个线程（避免线程切换），处理连接和请求；注意Worker进程的个数由配置文件决定，一般和CPU个数相关（有利于进程切换），配置几个就有几个Worker进程。

一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。

4.4 多进程模型的优点

1. 对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销。
2. 采用独立的进程，可以让worker互相之间不会影响，一个worker退出后，其它worker还在工作，服务不会中断，master进程则很快启动新的worker进程。

4.5 异步非阻塞IO事件模型

nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。

Nginx采用了Linux的epoll模型，epoll模型基于事件驱动机制，它可以监控多个事件是否准备完毕，如果OK，那么放入epoll队列中，这个过程是异步的。worker只需要从epoll队列循环处理即可。

和Java的NIO类似。

5. Nginx如何做到热部署

所谓热部署，就是配置文件nginx.conf修改后，不需要stop Nginx，不需要中断请求，就能让配置文件生效！（nginx -s reload 重新加载/nginx -t检查配置/nginx -s stop）

通过上文我们已经知道worker进程负责处理具体的请求，那么如果想达到热部署的效果，有两种方法：

1. 方案一，修改配置文件nginx.conf后，主进程master负责推送给woker进程更新配置信息，woker进程收到信息后，更新进程内部的线程信息。
2. 方案二，修改配置文件nginx.conf后，重新生成新的worker进程，当然会以新的配置进行处理请求，而且新的请求必须都交给新的worker进程，至于老的worker进程，等把那些以前的请求处理完毕后，kill掉即可。

Nginx采用的就是方案二来达到热部署的！

6. Nginx可靠性

Nginx既然作为入口网关，很重要，如果出现单点问题，显然是不可接受的。

答案是：Keepalived+Nginx实现高可用。

Keepalived是一个高可用解决方案，主要是用来防止服务器单点发生故障，可以通过和Nginx配合来实现Web服务的高可用。（其实，Keepalived不仅仅可以和Nginx配合，还可以和很多其他服务配合）

Keepalived+Nginx实现高可用的思路：

1. 请求不要直接打到Nginx上，应该先通过Keepalived（这就是所谓虚拟IP，VIP）。
2. Keepalived应该能监控Nginx的生命状态，提供一个用户自定义的脚本，定期检查Nginx进程状态，进行权重变化,，从而实现Nginx故障切换。