1.什么是nginx热部署？
- （1）先来说一下运行nginx服务开启的进程情况
Ngnix中的进程分为两类，一类是master进程，一类是worker进程
其中master进程是用来管理监控控制其下边的worker进程的主进程，这个进程由root发起
其中原因是http这个服务需要启用80端口，而只有root才有权限启用80端口
而顾名思义，worker进程才是真正working的进程，才是真正处理请求的进程
这些进程全部都是master进程的子进程，这些进程是以普通用户的身份进行运行的，这样就可以极大增加程序的安全性
就算是万一有一个进程被劫持，那也不会有管理员权限
Worker进程中，原生的功能只有最基本的web服务
但是由于nginx是高度模块化的应用程序，所以，在每一个worker进程中，有着一个或者多个模块
但是需要注意的是，装载的模块可不是全部一次加载进去的，只有当这个进程真的需要这个模块的时候，才会被这个工作进程加载
在我看来，模块化的思想和面向对象的思想，是推动现代整个开发的重要思想
由于nginx这个高度模块化的机制，也成就了其高效轻量的特点 - （2）进行热部署的前提条件（也就是为什么nginx可以进行热部署）
nginx 的热部署和其并发模型有着密不可分的关系，是因为 master 进程和worker进程的关系
当系统通知 ngnix 重读配置文件的时候，master 进程会进行语法错误的判断
如果存在语法错误的话，返回错误，不进行装载；如果配置文件没有语法错误，那么 ngnix 也不会将新的配置调整到所有 worker 中
而是，先不改变已经建立连接的 worker，等待 worker 将所有请求结束之后，将原先在旧的配置下启动的 worker 杀死
然后使用新的配置创建新的 worker
所以可以做到在线更新版本，新版本和旧版本的进程可以同时存在，不影响客户的访问 - （3）什么是热部署
热部署在nginx中还是一个强大的功能，就是在线升级
其原理就是首先我们先会替换master进程，同时我们替换的master是与老版本的worker兼容的
下一步，就是想大家已经想到的一样。保持还有连接的worker进程，待其老去退休，进行替换
高度的模块化加上精巧的两层模型，让ngnix成为大家非常热爱的web service实现的方案
nginx支持热加载热部署 ，其实就是在不打断用户请求的情况下更新版本，也就是在线更新版本
2.热部署的分类？
- （1）热部署成功（平滑更新）
在线更新nginx服务的版本并且更新成功，这个时候nginx的新版本和旧版本进程都可以同时工作，不影响客户的正常访问 - （2）热部署失败（回滚）
在线更新nginx服务的版本并且更新失败，这个时候就直接回退到原来的nginx版本进程，保证客户可以正常访问
3.实验环境
在上一个实验的基础上来做
| 主机信息 | 主机功能 |
|---|---|
| server1（172.25.8.1） | nginx服务器 |
| 真机（172.25.8.250） | 客户端，用来测试 |
上一个实验我们已经安装了1.16版本的nginx服务，现在我在这个基础上将nginx更新到1.17版本，并且再回退到1.16版本
不过上一个实验我们注释了版本显示，更新和回滚要看到版本才能直观的看到实验是否成功
我先把版本注释取消
这里的进程号指的是master，因为通过master进程来控制worker进程
4.nginx版本更新
一天只能更新一次，实际企业当中也不是每天都更新
cd /usr/local/nginx
./sbin/nginx -v 查看版本
./sbin/nginx -V 查看版本
ps ax
接下来做更新
- （1）从真机给nginx服务器传送一个1.17版本的nginx
- （2）在nginx服务器上面做更新
make后objs/下出现了二进制执行文件
make install 实际上就是将二进制执行文件和一些配置文件复制到/usr/local/nginx目录下
ps -ef | grep nginx可以看到原来的2个进程
kill -USR2 原来master进程的pid
ps -ef | grep nginx可以看到4个进程（新版本已经可以用了）
kill -WINCH 原来master进程的pid关闭原来进程的子进程，master不结束，防止更新失败
ps -ef | grep nginx可以看到3个进程（新版本已经可以用了）
/usr/local/nginx/sbin/nginx -V可以看到版本已经更新了
虽然当前版本已经变成了1.17版本，这个时候表面上看起来是更新成了新版本
但还是旧版本的在工作，接收客户端请求的仍然是1.16版本的nginx，这就有了下面的平滑升级
kill -USR2 旧版本的主进程号 （让旧版本的worker进程不再接受请求）
kill -WINCH 旧版本的主进程号 （关闭旧版本的worker进程）
总结：以上就是实现更新的步骤
5.nginx版本更新失败之后的回滚
更新完毕后如果出现问题，我们立马停止更新的进程，回滚到原来版本的进程上面
这就是没有强制结束旧版本的master进程的原因，因为可以通过旧版本的master进程将旧版本的worker进程调用回来
加入我们刚才的更新失败，现在要回到原来的1.16版本
kill -HUP 将原来主进程的子进程恢复
ps -ef | grep nginx可以看到4个进程（新版本已经不可以用了）
kill -WINCH 新版本的进程id
ps -ef | grep nginx可以看到3个进程（新版本的master进程已经备撤销了）
kill -HUP 旧版本的进程号 （拉起旧版本的worker进程）
kill -WINCH 新版本的主进程号 （关闭新版本的worker进程）
其实最后剩余的新版本的worker进程也可以强制结束了，因为已经更新失败
cd nginx-1.16.1/
ls
cd objs/
cp -f nginx /usr/local/nginx/sbin/nginx
ps -ef | grep nginx
因为已经更新失败，新版本产生的进程已经全部结束
可以看到回滚已经成功，并且其它的新版本的进程已经全部结束
客户仍然可以正常访问nginx服务器
实际在企业当中，如果更新失败立马就要回滚，并且更新的时候只能进行一次，失败立马回滚
注意：有时候编译之前需要 yum install -y pcre-devel zlib-devel gcc，解决安装的依赖性问题
