cover20220907.png
- 字数：961字
- 完稿用时：1小时26分(中间出去群聊了会)
- 完稿时速：670字/时
- 发稿用时：20分钟(发到gzh时发现表格的形式显示不友好，就花了点时间排版)
一直没系统的学习过前后端(主业是游戏开发)。
毕竟工作之余不多花时间，只靠上班那点时间的话，确实没有学习的机会。
因为工作中会用到openresty，也有过一点经验，所以打算稍仔细了解一下Nginx。
Nginx命令
| 命令 | 说明 | 与kill命令对应 |
|---|---|---|
| nginx | 会读取默认的配置文件 | |
| nginx -c xxx.conf | 另行指定配置文件 | |
| nginx -p nginx项目目录 | 指定项目根目录 | |
| nginx -g "pid /var/nginx/test.pid;" | 临时指定一些全局配置项 | |
| nginx -t | 仅测试配置文件是否有错误 | |
| nginx -t -q | 可以在测试时，不输出error级别以下的信息 | |
| nginx -v | 显示版本信息 | |
| nginx -V | 显示更多信息，如编译阶段的配置信息。 | |
| nginx -s stop | 强制停止Nginx服务，与kill命令的作用相同 |
kill -s SIGTERM <nginx master pid> 或 kill -s SIGINT <nginx master pid>
|
| nginx -s quit | 可以"优雅"地停止服务，会先关闭监听端口，停止接收新的连接，然后把当前正在处理的连接全部处理完，最后再退出进程。 | kill -s SIGQUIT <nginx master/worker pid> |
| nginx -s reload | 使运行中的nginx重读配置并生效。事实上，Nginx会先检查新的配置项是否有误，如果全部正确就以“优雅”的方式关闭，再重新启动Nginx来实现这个目的。 | kill -s SIGHUP <nginx master pid> |
| nginx -s reopen | 内核是根源文件描述符来定位文件的，所以就算文件名发生了修改，nginx依然可以把日志写进去。先对日志文件改名，再使用-s reopen命令，nginx将会把日志内容写入新的文件中，这样可以使日志文件不至于过大。 | 用kill命令也可以kill -s SIGUSR1 <nginx master pid>
|
| nginx -h | 显示帮助 | |
| 略(用到时再看书) | 平滑升级nginx到新的版本 |
-s是发送信号，所以用kill命令和使用nginx命令可以达到同样的效果。
为什么强调这个呢？
因为我有一次在DockerFile中看到这样一行配置"STOPSIGNAL SIGQUIT"，我网上查了一下，只大概知道它的意思是在容器关闭时，会发送信号"SIGQUIT"。
现在我知道，这行指令意味着，当容器关闭时，nginx将收到"-s quit"命令，也就是说nginx将"优雅"地停止服务。
不断学习的过程中也要不断反思
说实话，我看书学习的经验并不多，今天就感觉自己看书学习是有效率问题的。
下面是今天的一些感悟：
- 对于需要多操作的技能，看书学习或许还是适合快速过一遍，绝不能慢慢仔细看，要注意效率。
- 学习的时候一定要计时，时间不多了的时候，要迫使自己更快的学习。
- 最好的学习方式是输出，以输出倒逼输入。输出出去的话，我也怕别人想，这家伙是不是不会学习，这家伙学习也太慢了吧。但我还是要分享出去，不分享出去只会掩盖自己的问题。
- 工作时间还是要退出微信的，一直没做到。
- 要清楚什么是最重要的，持续学习比选择什么学习工具重要的多。
- 越是容易做不好的地方，越要暴露出来，比如"发稿用时"，有时会花太多时间，比如花了好久去找一首背景音乐，对于目前的我来说没有必要。所以把用时放出来，迫使自己专注，做的不好了，大家可以看到。(希望不要最后只是练就了一个厚脸皮)
- 关于写文章有句话："允许自己写出最烂的文章"，关于学习也一样，允许自己做学习能力最差的程序员，即使做的不好，也要把学习的过程以及学到的东西，勇敢的写出来！别人看了，有帮助，最好。没帮助也没关系，自己受益了就好。
网友评论