一、配置文件中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平滑重启
重启包括:
- 重启服务: service nginx restart
- 快速停止或关闭Nginx:nginx -s stop
- 正常停止或关闭Nginx,不接受新的连接请求,等待旧的连接请求处理完毕再关闭:nginx -s quit
- 配置文件修改重装载命令1:nginx -s reload
- 配置文件修改重装载命令2:kill -HUP nginxPid
我们来讨论下 kill -HUP nginxPid(同reload)
当 nginx 接收到 HUP 信号,它会尝试先解析配置文件(如果指定配置文件,就使用指定的,否则使用默认的),成功的话,就应用新的配置文件(例如:重新打开日志文件或监听的套接 字)。之后,nginx 运行新的工作进程并从容关闭旧的工作进程。通知工作进程关闭监听套接字但是继续为当前连接的客户提供服务。所有客户端的服务完成后,旧的工作进程被关闭。 如果新的配置文件应用失败,nginx 将继续使用旧的配置进行工作。
摘抄自:Nginx文档
在重载前,要先测试一下配置文件:
/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
测试逻辑
- 在nginx启动时,修改/usr/local/nginx/html/index.html,复制一份为index2.html,并将其在nginx.conf中配置到index的左侧。test配置文件有效性,kill -HUP nginxPid 的同时 浏览器不断刷新,页面内容会从index.html转为index2.html,此时ps查看nginx的pid,并没有发生变化
- 重复测试上述步骤,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负载均衡
我们根据策略进行测试:
- 默认轮询:可加权重等其他信息
- ip_hash:ip hash
- 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可以判断出来而把请求都分发给正常的服务器吗?