后端集群指令

upstream 和 server 指令互相配合，用于配置一个我们在上篇文章中提到的后端集群。这个集群中的所有服务器都提供相同的功能，Nginx 可以通过不同的负载均衡策略将请求分发给不同的后端服务器。因为针对不同的集群，我们可以使用不同的负载均衡策略，所以负载均衡策略是和 upstream 配合使用的。

server 指令

server 指令用于指定集群中的后端服务器实例。我们可以使用域名，ip 及端口的方式进行配置。
服务器还有很多属性，我们可以通过这些属性字段对服务器进行修饰，比如权重，最大连接数，失败连接数等等。

upstream backend {
    # 下面定义了四个后端服务器，形成了一个后端集群
    server backend1.example.com weight=5;
    server backend2.example.com max_fails=3;
    server backend3.example.com;
    server 127.0.0.1：8080; #ip+端口的格式
}

对于上面的例子来说，Nginx 将使用加权轮训的机制在所有后端服务器之间分发请求。每 8 个请求的分发如下：

• 5 个请求被分发给 backend1.example.com
• 剩下的 3 个请求被平均分配给了其余三个后端服务器
• 当一个后端服务器发生错误的时候，会选择下一个服务器，知道所有的服务器都被重试。

定义前端服务器配置文件 nginx.conf，这个服务器主要是用来接收用户端的请求，然后根据负载均衡策略选择不同的服务器。

在这里我们定义了包含了两个后端服务器的集群。我们使用了默认的加权轮训策略，因为第一台服务器 www.backend1.com 的权重是 3，第二台服务器的权重是 1，所以正常情况下每四个请求中会有三个请求被第一个后端服务器处理，剩下的一个被第二个后端服务器处理。

GZIP功能

GZIP是一种压缩算法，可以把一些大文件压缩为小文件，浏览器在接收到压缩文件的时候，会根据压缩算法解压文件，这样就可以减少网络传输过程中的带宽消耗和时间消耗。
Nginx中通过ngx_http_gzip_module模块实现gzip压缩。

不使用gzip压缩

• 配置nginx不打开gzip，配置如下：

使用gzip压缩

• 将nginx配置打开gzip，配置如下：

对比我们使用gzip前后的操作：
首先，使用gzip压缩之后的体积是之前的1/40左右，传输体积大大的减小了。
其次，使用gzip之后传输耗时从217ms降低到了125ms，耗时降低了将近一半。

除了上面的方法之外，我们也可以通过响应头部来确认是否启用了gzip压缩。

gzip

毫无疑问这个指令时最重要的，它表示是否使用gzip压缩内容。

gzip_comp_level压缩率

这个参数是一个1~9的数值，数值越大，表示压缩比率越高，压缩之后的文件体积越小，传输的越快。
但是这个值并不是越大越好。压缩操作是一个耗CPU的操作，压缩比越大，压缩本身耗时就越多，并且随着压缩比率的提高，文件体积减小的并不是特别明显，所以并不要将这个值设置的特别大，建议设置为4~6。

gzip_min_length起始压缩长度

gzip是一种压缩算法，它会在最终的压缩内容中增加一些标识字段，这样浏览器收到内容之后可以根据这些内容进行解压操作。所以对于体积比较小的内容，尽量不要进行压缩。这样可以节约一些时间。

我曾经对一个空字符串进行过gzip压缩，结果压缩之后的长度居然变成了20~

gzip_types压缩文件类型

这个配置项表示的是要对哪些文件类型进行压缩。默认情况下只对text/html类型的文件进行压缩，如果我们想对css以及js文件进行压缩，可以将这些文件对应的MIME Type添加到这个配置项中。
有一个特殊的*，这个值表示对所有的文件类型都进行压缩操作。

上面几个配置项是我们使用gzip过程中经常会用到的选项，我们要牢记这几个的作用。

注意事项

既然gzip这么犀利，那是不是所有的资源都可以进行压缩呢？其实不然，对于文本文件，比如html, css, js等，可以使用gzip进行压缩。而有一些资源则尽量不要进行压缩。

• 图片资源：比如png, jpg类型的图片，他们本身就已经进行了压缩。所以，即使使用了gzip压缩，压缩前后体积大小也不会有明显的变化。甚至会变得更大(因为增加了gzip特有的字段)。Google, baidu都没有对图片进行压缩。
• 大文件和视频类型：压缩这些文件会消耗大量的CPU，并且压缩之后也不一定符合我们的预期。
• 特别小的文件：对这些小文件的压缩，可能会导致越压缩体积越大的尴尬现象（具体原因我们已经在上面阐述）。