Nginx学习----Nginx平滑重启+负载均衡测试

一、配置文件中pid的作用?

上一篇Nginx学习----Nginx配置反向代理、负载均衡中，对这个pid没有太理解

#通过 PID 文件可以判断是否已经有一个实例正在运行。防止意外启动多个进程实例
pid   /var/run/nginx.pid;

重装了nginx,本来测试kill -HUP pid 重新读取配置文件，不小心将启动命令执行了两次，准备kill的时候发现：

[root@iZuf66kf0lsrq5yfg4ymjlZ nginx]# ps -ef|grep nginx
root      968928       1  0 09:17 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    968929  968928  0 09:17 ?        00:00:00 nginx: worker process
root      968959       1  0 09:23 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    968960  968959  0 09:23 ?        00:00:00 nginx: worker process
root      968962  968870  0 09:23 pts/2    00:00:00 grep --color=auto nginx

于是配置pid文件路径，重新执行上述步骤：
注意：将默认关闭的打开即可，或者指定路径，如 /var/run/nginx.pid;

# pid        logs/nginx.pid;

启动前可以test下配置文件的正确性

sbin/nginx -t -c conf/nginx.conf
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

多次启动后：

[root@iZuf66kf0lsrq5yfg4ymjlZ nginx]# sbin/nginx -c conf/nginx.conf             
[root@iZuf66kf0lsrq5yfg4ymjlZ nginx]# sbin/nginx -c conf/nginx.conf
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

查看进程：

[root@iZuf66kf0lsrq5yfg4ymjlZ nginx]# ps -ef|grep nginx
root      969091       1  0 10:01 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    969092  969091  0 10:01 ?        00:00:00 nginx: worker process
root      969102  968985  0 10:07 pts/3    00:00:00 grep --color=auto nginx

一、Nginx平滑重启

重启包括：

1. 重启服务： service nginx restart
2. 快速停止或关闭Nginx：nginx -s stop
3. 正常停止或关闭Nginx，不接受新的连接请求，等待旧的连接请求处理完毕再关闭：nginx -s quit
4. 配置文件修改重装载命令1：nginx -s reload
5. 配置文件修改重装载命令2：kill -HUP nginxPid

我们来讨论下 kill -HUP nginxPid（同reload）

当 nginx 接收到 HUP 信号，它会尝试先解析配置文件（如果指定配置文件，就使用指定的，否则使用默认的），成功的话，就应用新的配置文件（例如：重新打开日志文件或监听的套接 字）。之后，nginx 运行新的工作进程并从容关闭旧的工作进程。通知工作进程关闭监听套接字但是继续为当前连接的客户提供服务。所有客户端的服务完成后，旧的工作进程被关闭。 如果新的配置文件应用失败，nginx 将继续使用旧的配置进行工作。

摘抄自：Nginx文档
在重载前，要先测试一下配置文件：
/usr/sbin/nginx -t -c /etc/nginx/nginx.conf

测试逻辑

1. 在nginx启动时，修改/usr/local/nginx/html/index.html，复制一份为index2.html，并将其在nginx.conf中配置到index的左侧。test配置文件有效性，kill -HUP nginxPid 的同时 浏览器不断刷新，页面内容会从index.html转为index2.html，此时ps查看nginx的pid，并没有发生变化
2. 重复测试上述步骤，cd到nginx目录下，sbin/nginx -c conf/nginx.conf -s reload 方式，效果同上，且此时ps查看nginx的pid，并没有发生变化。

脚本快捷命令

一般生产环境会使用脚本启动，如下：下载地址

也可以通过vim创建：
[root@localhost ~]# vim /etc/init.d/nginx

NGINX=/usr/local/nginx/sbin/nginx
PID=/usr/local/nginx/logs/nginx.pid
start()
{
	if [ -f $PID ] 
	then
		echo "nginx已经启动!"
	else
		$NGINX
		echo "nginx启动成功!"
	fi
}
stop()
{
	if [ -f $PID ]
	then
		killall -s QUIT nginx
		echo "nginx已经关闭!"
	else
		echo "nginx未启动!"
	fi
}
restart()
{	
	if [ -f $PID ]
	then
		stop
	fi
	start
}
reload()
{
 kill -s HUP $(cat $PID)
}
case $1 in
"start") start
	;;
"stop") stop
	;;
"restart") restart
	;;
"reload") reload
	;;
*) echo "请输入正确的操作参数start|stop|restart|reload"
	;;
esac

创建好后需要执行chmod命令将其变为可执行文件，如chmod 777 nginx

二、Nginx负载均衡

我们根据策略进行测试：

1. 默认轮询：可加权重等其他信息
2. ip_hash：ip hash
3. least_conn：最少访问

准备部署两个简单项目，端口不同用于标识服务，启动jar

nohup java -jar hello2.jar >catalina.out  2>&1 &

nohup command > /dev/null 2>&1 &

nohup 代表忽略hup信号， & 代表以后台job形式运行 command > /dev/null 代表stdout输出到空文件 2>&1 中的2>代表stderr输出，&1代表前面/dev/null的引用（文件描述符）而已，这种写法减少文件IO操作，效率高

这里/dev/null这个目录表示黑洞，即支持写入的空文件。这个在nginx的配置文件中，要想关闭error_log,只有一种方式：把他输出到/dev/null这个目录下。详见Nginx学习----Nginx配置反向代理、负载均衡

批量发送请求采用postMan,比较简单，可以参考博客：批量发送请求
未添加nginx之前的访问：

1.默认轮询

主要修改配置如下：下载链接nginx.conf

 upstream project_name {
 server 127.0.0.1:8885 weight=100 max_fails=3 fail_timeout=5s;
 server 127.0.0.1:8886 weight=100 max_fails=3 fail_timeout=5s;
}
server {
  # START BASIC CONFIG
  listen 80;

  server_name localhost
  ....
   location /login2 {
    proxy_pass        http://project_name;

注意：project_name指向的就是负载均衡的名称
修改后，平滑重启：采用上一节的脚本：/etc/init.d/nginx reload
测试：1. 访问100次，2.以是否返回的是hello2字符串为判断标准，如下：

通过上图，轮询的是1：1的,现在修改权重，改为9：1，reload后重复测试，如下图：

server 127.0.0.1:8885 weight=9 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

ip_hash

修改配置：

ip_hash;
server 127.0.0.1:8885 weight=9 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

由于我本地ip相同，结果都是一致的，只能算是个正向测试。

least_conn最少访问

least_conn算法很简单，首选遍历后端集群，比较每个后端的conns/weight，选取该值最小的后端。

如果有多个后端的conns/weight值同为最小的，那么对它们采用加权轮询算法。

server 127.0.0.1:8885 weight=2 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

那nginx负载和springcloud的gateWay有什么区别呢？

nginx的负载均衡是为了承压，gateWay更像是业务分发，抽取各服务的通用功能

参考博客：
Nginx可以做什么？看完这篇你就懂了

如果其中一个服务挂了，nginx可以判断出来而把请求都分发给正常的服务器吗？