Linux下Nginx的基础使用

最近又在玩了下linux，这次记录nginx的安装使用吧，好像这篇没什么技术似的，网上太多教程了，算了，作为自己的一个笔记吧！

首先得有一台linux系统的电脑，把自己的电脑装成linux这个就没必要了，毕竟平常使用还是win的。那么可以注册下阿里云服务器，新用户有免费试用时间，还可以丢点自己的网站或静态页面上去，给别人看看。或者用虚拟机，我比较习惯用vm，用虚拟机，要想外网能访问得到也是可以的，不过你的宽带得有外网ip（为什么说要外网ip，其实有的城中村你装4M或多少的时候，他是没有给你一个独立的宽带的，可能是一个10M的宽带，他分成了2个4M和1个2M，以提供一个低价，这个时候你路由器的ip是那个10M宽带的分配出来的，在外网根本访问不到，就像学校的一样），然后在路由器里设置一下端口映射到你对应的ip和端口就行了。

进入正文，这次是在阿里云服务器上安装及使用Nginx。

基础使用那肯定是用yum来安装了便捷简易，由于那个啥，所以我们第一件事肯定是先把镜像换成国内的，这里我选择阿里云的。

//安全起见，先备份下原始的
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup

//下载阿里云的镜像
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
//或
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

//更新缓存
yum clean all
yum makecache

接下来就是用yum安装nginx了。

sudo yum -y install nginx

安装完我们就可以使用了，首先启动下服务验证下

//启动linux服务
systemctl start nginx.service
//设置自启
systemctl enable nginx.service

这时候我们访问本地ip，如果出现nginx的页面那就是安装启动成功了。我们的nginx便可以使用了。就是这么简单。

接下来我们肯定要做映射的，配置文件在/etc/nginx/nginx.con中。

首先把字符编码改为UTF-8吧，以防有中文路径打不开（有人会说，怎么会有中文，举个例子，比如图片，或者Axure导出的原型）

一般使用主要配置有两种，

1、重定向到其他端口或其他服务器（适合配合tomcat等）

location / {
            #root   html;
            #index  index.html index.htm;
	    proxy_pass        http://localhost:8088;  //真正应用地址
            proxy_redirect    off;
            //设置请求头
            proxy_set_header  Host  $host;  
            proxy_set_header  X-Real-IP $remote_addr;
            proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;

        }

2、直接指向文件（适用没安装应用服务器，或直接打开静态文件，比如Axure导出的原型）

	location /html { //地址路径
            root D:/table/;
            index index.html;
            autoindex on;//开启目录访问
	    autoindex_exact_size off;
            autoindex_localtime on;
        }

负载均衡、集群配置

既然用了nginx在条件允许下我们肯定要做下集群来应付负载的，也许说改产品的并发量不大，但是如果是在持续迭代更新的产品做下负载均衡也是极好的，因为他还可以无缝更新，这样就不用挑晚上没客户使用的时候再去更新了，比如有两台服务器做集群，那么可以先停了A服务器去更新（nginx会把请求分发给B服务器），A更新好启动后再停了B服务器去更新，这样在更新的过程中，我们的应用还是可以正常使用的（但实际上还是有小影响的，比如在停A的时候，已经连接上A的请求，这次失败，这是会转发给B服务器，用户的等待时间就变长了，而post请求则会直接失败，下面会讲到）。

（1）配置集群

声明集群服务器

upstream serverName{
  server 192.168.1.100:80;
  server 192.168.1.101:80;
}

server配置中将地址执行集群服务器名称，如

server{
  location /{
	proxy_pass http://serverName;//负载均衡
  }
}

这样配置后，nginx默认是负载均衡的，再并发为4的时候，两台服务器会各分配两个请求，如果你100那台服务器配置比较好想让他处理较多请求，那可以配置个权重。如

upstream serverName{
  server 192.168.1.100:80 weight=3;//增加权重
  server 192.168.1.101:80;
}

在这种情况下，100那天服务器就会分配处理3个请求，101处理一个。

在nginx失败自动重试的机制下（在一台服务器处理失败的情况下，nginx会重试发个另一台处理，比如100处理失败了，nginx会发请求给101处理）需要注意重复多次请求的问题，比如nginx设置了5秒超时，这时A服务器由于内存或其他问题正常1s就能返回数据的接口，等了6秒还没处理完，这时nginx超时了，会把请求重新发给B服务器，但实际上A还在处理的，从而导致一个请求执行了两次，如果是查询那没什么影响，但是新增数据的话，就会产生重复的脏数据了，所以最后保持RESTful接口规范，http协议规定对post、lock、patch等幂等方法不进行故障转移（但nginx但请求没发出去时即连接不上，tcp连接还没建立，那nginx还是会重试post请求的）。

（2）雪崩

在上面说的nginx自动重试的故障转移机制下，会给其他正常的服务器分配更多的请求，从而在高并发的场景下有可能导致雪崩。

比如一个应用有5台服务器，每台能承受的高并发为10万个请求，在持续每秒50万个并发，nginx每次都给各服务器分配了10万个请求，服务器到了瓶颈，在持续一段时间后，比如A服务器由于内存释放不及时或其他问题，导致一个请求处理超时（服务器还没挂），这是nginx会把请求重新发给B，那么B接受了10万零1的并发导致B挂了，那么这10万个失败的请求nginx再分发给其他服务器，导致所有的原本正常的服务器都超负荷而奔溃了，这就是整个集群的雪崩效应。

对这种情况我们可以给nginx设置重试的次数及限制重试的最长时间

proxy_next_upstream_tries 2;//重试次数
proxy_next_upstream_timeout 60s;//限制重试的最长时间

这种配置下在上面的例子中，A一个请求超时，nginx重试了B和C服务器挂了，那么就不会重试下去了，从而保住了3台服务器的运行，这个时候运维或开发人员应该受到告警通知了，就应该及时去处理了，同时我们评估的时候应该预留些空间，比如使用场景高并发50万的，我们服务器应该要能承受51万的高并发这样比较保险。

（3）熔断机制

比如Nginx代理请求的超时时间为10秒。A服务器压力大，处理需要15秒导致超时，B服务器是正常处理紧1秒。如果nginx把请求分配给A服务器等10秒后超时，再转移给B，对于用户来说就花费了11秒，体验不好，如果A整个应用都这样，所有的接口都会超时，那么其实对于nginx来说这台服务器就跟挂了没什么区别，那我们就不应该让他一直分配给这台服务器，这就需要配置下熔断机制，配置错误次数及熔断时间。即当某台被代理服务器处理请求，出现一定次数的错误（可配置）的情况下，Nginx在一定时间（可配置），不再将请求分配给该服务器处理，过了熔断时间后，nginx会再次尝试分配一次请求给该服务器处理，如还是失败，则继续熔断。如：

upstream serverName{
  server 192.168.1.100:80 weight=3;//权重3
  server 192.168.1.101:80 max_fails=3 fail_timeout=10s;//请求失败次数后就熔断和熔断时间（即隔多久后才重试）
}

在这种配置下如果A服务器连续失败3次，那么下次就不再把请求发给A，直到10s后才会发给A一次，如果正常请求成功，那么就恢复正常，如失败那就再隔10s后才会发请求给A，这个时候相关人员就需要去排查原因了。

基本就这样吧！最近在玩公众号，把文章搬了一份到公众号，优秀的你们可以关注下