Nginx笔记

Nginx（发音同engine x）

 

Nginx的运行速度的确很快，耗用的资源却比Apache或IIS服务器少得多。能有如此傲人的表现，归因于它是基于事件的。这意味着，Nginx并不为每一个网页请求创建新的进程或线程。最终结果就是，即使负载加大后，内存方面的使用仍是可以预测的.

 

Nginx还可以用来改进性能，因为它可以作为反向代理系统来使用。在这种模式下，Nginx在用户们看来完全如同另一台Web服务器。不过在幕后，该反向代理系统用来对几个后端服务器之间的Web请求进行负载均衡，或者为一台速度比较慢的后端服务器提供缓存机制。

 

在负载均衡的角度上，可以对比LVS（Linux Virtual Server）

 

Nginx 提供了两种全异步方式与第三方服务进行通信：upstream 和subrequest。

upstream 在与第三方服务器交互时（包括建立TCP 连接、发送请求、接收响应、关闭TCP 连接），不会阻塞Nginx 进程处理其他请求。

subrequest 只是分解复杂请求的一种设计模式，它可以把原始请求分解为多个子请求，使得诸多请求协同完成一个用户请求，并且每个请求只关注一个功能。subrequest 访问第三方服务最终也是基于upstream 实现的。

upstream 被定义为访问上游服务器，它把Nginx 定义为反向代理服务器，首要功能是透传，其次才是以TCP 获取第三方服务器的内容。Nginx 的HTTP 反向代理模块是基于 upstream 方式实现的。

subrequest 是子请求，也就是说subrequest 将会为用户创建子请求，即将一个复杂的请求分解为多个子请求，每个子请求负责一种功能项，而最初的原始请求负责构成并发送响应给用户。当subrequest 访问第三服务时，首先派生出子请求访问上游服务器，父请求在完全取得上游服务器的响应后再决定如何处理来自客户端的请求。

因此，若希望把是第三方服务的内容原封不动地返回给用户时，则使用 upstream 方式。若访问第三方服务是为了获取某些信息，再根据这些信息来构造响应并发给用户，则应使用 subrequest 方式。

 

upstream 机制的负载均衡

upstream 机制使得 Nginx 以反向代理的形式运行，因此 Nginx 接收客户端的请求，并根据客户端的请求，Nginx 选择合适后端服务器来处理该请求。但是若存在多台后端服务器时，Nginx 是根据怎样的策略来决定哪个后端服务器负责处理请求？这就涉及到后端服务器的负载均衡问题。
Nginx 的负载均衡策略可以划分为两大类：内置策略 和 扩展策略。内置策略包含 加权轮询 和 IP hash，在默认情况下这两种策略会编译进 Nginx 内核，只需在 Nginx 配置中指明参数即可。扩展策略有第三方模块策略：fair、URL hash、consistent hash等，默认不编译进 Nginx 内核。本文只讲解 加权轮询 和 IP_hash 策略。

 

加权轮询策略：不依赖于客户端的任何信息，完全依靠后端服务器的情况来进行选择。但是同一个客户端的多次请求可能会被分配到不同的后端服务器进行处理，无法满足做会话保持的应用的需求。

IP哈希策略：把同一个 IP 地址的客户端请求分配到同一台服务器处理，避免了加权轮询无法适用会话保持的需求。但是来自同一的 IP 地址的请求比较多时，会导致某台后端服务器的压力可能非常大，而其他后端服务器却空闲的不均衡情况。