## 六、浏览器本地缓存配置
语法：expires 60 s|m|h|d
```
动静分离效果:
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html;
}
location ~ \.(png|jpg|js|css|gif)$ {
root html/images;
expires 5m;
}
}
```
## 七、Gzip压缩策略
浏览器请求 -> 告诉服务端当前浏览器可以支持压缩类型->服务端会把内容根据浏览器所支持的压缩策略去进行压缩返回
->浏览器拿到数据以后解码； 常见的压缩方式：gzip、deflate 、sdch
Gzip on|off 是否开启gzip压缩
Gzip_buffers 4 16k
设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。4 16k代表以16k为单位，安装原始数据大小以16k为单位的4倍申请内存。
Gzip_comp_level[1-9]
压缩级别， 级别越高，压缩越小，但是会占用CPU资源
Gzip_disable #正则匹配UA 表示什么样的浏览器不进行gzip
Gzip_min_length 开始压缩的最小长度（小于多少就不做压缩）
Gzip_http_version
1.0|1.1 表示开始压缩的http协议版本
Gzip_proxied （nginx 做前端代理时启用该选项，表示无论后端服务器的headers头返回什么信息，都无条件启用压缩）
Gzip_type
text/pliain,application/xml 对那些类型的文件做压缩 （conf/mime.conf）
Gzip_vary
on|off 是否传输gzip压缩标识
```
server {
listen 80;
server_name localhost;
gzip on;
gzip_buffers 4 16K;
gzip_comp_level 7;
gzip_min_length 500;
gzip_types text/css text/xml text/javascript;
location / {
root html;
index index.html;
}
location ~ \.(png|jpg|js|css|gif)$ {
root html/images;
expires 5m;
}
}
```
**注意点**
1. 图片、mp3这样的二进制文件，没必要做压缩处理，因为这类文件压缩比很小，压缩过程会耗费CPU资源
2. 太小的文件没必要压缩，因为压缩以后会增加一些头信息，反而导致文件变大
3. Nginx默认只对text/html进行压缩 ，如果要对html之外的内容进行压缩传输，我们需要手动来配置
## 八、Nginx反向代理
location {proxy_pass}
```
server {
listen 80;
server_name www.gerry.com;
location =/s {
proxy_pass http://www.baidu.com;
}
}
```
Proxy_pass 既可以是ip地址，也可以是域名，同时还可以指定端口
Proxy_pass指定的地址携带了URI，看我们前面的配置【/web】，那么这里的URI将会替换请求URI中匹配location参数部分；如上代码将会访问到http://www.baidu.com/web
## 九、负载均衡
*upstream*是Nginx的HTTP Upstream模块，这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡
### 1、Upstream常用参数介绍
**语法：**server address [parameters]
其中关键字server必选。
address也必选，可以是主机名、域名、ip或unix socket，也可以指定端口号。
parameters是可选参数，可以是如下参数：
? **down**：表示当前server已停用
? **backup**：表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或者很忙才会分配到请求
? **weight**：表示当前server负载权重，权重越大被请求几率越大。默认是1
**max_fails**和**fail_timeout**一般会关联使用，如果某台server在fail_timeout时间内出现了max_fails次连接失败，那么Nginx会认为其已经挂掉了，从而在fail_timeout时间内不再去请求它，fail_timeout默认是10s，max_fails默认是1，即默认情况是只要发生错误就认为服务器挂掉了，如果将max_fails设置为0，则表示取消这项检查。
```
upstream tomcatserver {
server 192.168.3.220:8080;
server 192.168.3.222:8080 weigth=4;
}
```
### 2、ups支持的调度算法
在做负载均衡前，我们首先需要定义一个 Server 组用来表示所有存在的后台服务：
```
http {
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}
}
```
然后，我们需要把流量重定向到上一步定义的 backend 上去, 我们可以通过指定 proxy_pass 的值来完成这一操作：
```
upstream backend {
server backend1.example.com;
server backend2.example.com;
server 192.0.0.1 backup;
}
server {
location / {
proxy_pass http://backend;
}
}
}
```
这里我们将所有的流量重定向到 [http://backend](https://link.juejin.im?target=http%3A%2F%2Fbackend) , 这将这个 NGINX 实例上的所有流量重定向到之前定义的 backend 上去。
### 负载均衡算法
当没有指定任何信息时， NGINX 默认使用了 Round Robin(轮询)算法来重定向流量。其实 NGINX 提供了多种算法来做负载均衡，下面我们来介绍一下：
### 1、Round Robin (轮询)
在没有指定 weight(权重) 的情况下，Round Robin 会将所有请求均匀地分发给所有后台服务实例：
```
upstream backend {
server backend1.example.com;
server backend2.example.com;
}
```
这里我们没有指定权重，所以两个后台服务会收到等量的请求。但是，当指定了权重之后，NGINX 就会将权重考虑在内：
```
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
}
```
在 NGINX 中，weight 默认被设置为 1。这里我们用一开始的配置举例， [backend1.example.com](https://link.juejin.im?target=http%3A%2F%2Fbackend1.example.com) 的权重被设置为 5，另一个的权重没设置，所以是默认值 1。我们也没有设置轮询算法，所以这时候 NGINX 会以 5：1 的比例转发请求，即 6 个请求中， 5 个被放到了 [backend1.example.com](https://link.juejin.im?target=http%3A%2F%2Fbackend1.example.com) 上， 有一个被发到了 [backend2.example.com](https://link.juejin.im?target=http%3A%2F%2Fbackend2.example.com) 上。
### 2、Least Connections（最少连接算法）
在这个模式下，一个请求会被 NGINX 转发到当前活跃请求数量最少的服务实例上：
```
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
```
我们用 least_conn 来指定最少连接优先算法, NGINX 会优先转发请求到现有连接数少的那一个服务实例上。
### 3、IP Hash (IP 哈希)
在 IP Hash 模式下，NGINX 会根据发送请求的 IP 地址的 hash 值来决定将这个请求转发给哪个后端服务实例。被 hash 的 IP 地址要么是 IPv4 地址的前三个 16 进制数或者是整个 IPv6 地址。使用这个模式的负载均衡模式可以保证来自同一个 IP 的请求被转发到同一个服务实例上。当然，这种方法在某一个后端实例发生故障时候会导致一些节点的访问出现问题。
```
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
```
如果某一台服务器出现故障或者无法进行服务，我们可以给它标记上 down，这样之前被转发到这台服务器上的请求就会重新进行 hash 计算并转发到新的服务实例上:
```
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
}
```
### 4、Generic Hash(通用哈希)
这个模式允许管理员自定义 hash 函数的输入，比如:
```
upstream backend {
hash $reqeust_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
```
在这个例子中，我们以请求中所带的 url 为 hash 的输入。 注意到这里在 hash 那一行的最后加入了 consistent 这个关键词。这个关键词会使用一种新的 hash 算法 [ketama](https://link.juejin.im?target=https%3A%2F%2Fwww.last.fm%2Fuser%2FRJ%2Fjournal%2F2007%2F04%2F10%2Frz_libketama_-_a_consistent_hashing_algo_for_memcache_clients), 该算法会让管理员添加或删除某个服务实例的时候，只有一小部分的请求会被转发到与之前不同的服务实例上去，其他请求仍然会被转发到原有的服务实例上去。
### 5、Random (随机算法)
顾名思义，每个请求都被随机发送到某个服务实例上去:
```
upstream backend {
random;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
```
Random 模式还提供了一个参数 two，当这个参数被指定时，NGINX 会先随机地选择两个服务器(考虑 weight)，然后用以下几种方法选择其中的一个服务器:
```
1. least_conn: 最少连接数
2. least_time=header(NGINX PLUS only): 接收到 response header 的最短平均时间
3. least_time=last_byte(NGINX PLUS only): 接收到完整请求的最短平均时间
```
我们可以参考下面的一个例子:
```
upstream backend {
random two least_time=last_byte;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
```
当环境中有多个负载均衡服务器在向后端服务转发请求时，我们可以考虑使用 Random 模式，在只有单个负载均衡服务器时，一般不建议使用 Random 模式。
### 6、Least Time (NGINX PLUS only)
这是一个 NGINX PLUS (NGINX 的付费版) 才有的模式，可以将请求优先转发给平均响应时间较短的服务实例，它也有三个模式:
```
1. header: 从服务器接收到第一个字节的时间
2. last_byte: 从服务器接收到完整的 response 的时间
3. last_byte inflight: 从服务器接收到完整地 response 的时间（考虑不完整的请求）
```
例子如下:
```
upstream backend {
least_time header;
server backend1.example.com;
server backend2.example.com;
}
```
## 总结
NGINX 提供了多种负载均衡模式，在实际使用中，需要根据实际业务需求去做尝试，分析日志来找到最适合当前场景的复杂均衡模式。
原文地址：https://www.cnblogs.com/xyj179/p/10708097.html