• Nginx的配置

    1运行中的Nginx进程间的关系

    1.在正式提供服务的产品环境下，部署Nginx时都是使用一个master进程来管理多个worker进程，一般情况下，worker进程的数量与服务器上的CPU核心数相等。每一个worker进程都是繁忙的，它们在真正地提供互联网服务，master进程则很“清闲”，只负责监控管理worker进程。

    问题一：
    Nginx是支持单进程（master 进程）提供服务的 那么为什么产品环境下要按照master和worker方式配置同时启动多个进程呢？这样做的好处主要有以下两点：
    ·由于master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程可以是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等。master进程需要拥有较大的权限，例如，通常会利用root用户启动mastcr进程。worker进程的权限要小于或等于master进程，这样master进程才可以完全地管理worker进程。当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。
    ·多个worker进程处理互联网请求不但可以提高服务的健壮性（一个worker进程出错后，其他workcer进程仍然可以正常提供服务），最重要的是，这样可以充分利用现在常见的SMP多核架构，从而实现微观上真正的多核并发处理。因此，用一个进程(master进程）来处理互联网请求肯定是不合适的。另外，为什么要把workcer进程数量设置得与CPU核心数量一致呢?这正是Nginx与Apache服务器的不同之处。在Apachc上每个进程在一个时刻只处理一个请求，因此，如果希望Wcb服务器拥有并发处理的请求数更多，就要把Apache的进程或线程数设置得更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程间切换将带来无谓的系统资源消耗。而Nginx则不然，一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心)，进程间切换的代价是最小的。

     2.Nginx配置的通用语法

    配置文件其实是一个文本文件

    1. user nobody;
    2. worker_processes 8;
    3. error_log varlog/nginx/error.log error;
    4. #pid logs/nginx.pid;
    5. events {
    6. use epoll;
    7. worker_connections 50000;
    8. }
    9. http {
    10. include mime.types;
    11. default_type application/octet-stream;
    12. log_format main '$remote_addr [$time_local] "$request" '
    13. '$status $bytes_sent "$http_referer" '
    14. '"$http_user_agent" "$http_x_forwarded_for"';
    15. access_log logs/access.log main buffer=32k;
    16. …
    17. ｝

    块配置

    块配置项由一个块配置项名和一对大括号组成 
    1. events {…
    2. }
    3. http {
    4. upstream backend {
    5. server 127.0.0.1:8080;
    6. }
    7. gzip on;
    8. server {
    9. …
    10. location /webstatic {
    11. gzip off;
    12. }
    13. }
    14. }
    上面代码段中的events、http、server、location、upstream等都是块配置项，块配置项之后是否如*1ocation/webstatic...}”"那样在后面加上参数，取决于解析这个块配置项的模块，不能一概而论，但块配置项一定会用大括号把一系列所属的配置项全包含进来，表示大括号内的配置项同时生效。所有的事件类配置都要在events块中，http、server等配置也遵循这个规定。
    块配置项可以嵌套。内层块直接继承外层块，例如，上例中， server 块里的任意配置都
    是基于 http 块里的已有配置的。当内外层块中的配置发生冲突时，究竟是以内层块还是外层
    块的配置为准，取决于解析这个配置项的模块。

    配置语法

    1. 配置项名
    2.         配置项值
    3.                 1 配置项值
    4.                        2 …
    下面解释一下配置项的构成部分。
    首先，在行首的是配置项名，这些配置项名必须是 Nginx 的某一个模块想要处理的，否 则 Nginx 会认为配置文件出现了非法的配置项名。配置项名输入结束后，将以空格作为分隔
    符。
    其次是配置项值，它可以是数字或字符串（当然也包括正则表达式）。针对一个配置
    项，既可以只有一个值，也可以包含多个值，配置项值之间仍然由空格符来分隔。当然，一
    个配置项对应的值究竟有多少个，取决于解析这个配置项的模块。我们必须根据某个 Nginx
    模块对一个配置项的约定来更改配置项

    配置项的单位

    大部分模块遵循一些通用的规定，如指定空间大小时不用每次都定义到字节、指定时间
    时不用精确到毫秒。
    当指定空间大小时，可以使用的单位包括：
    ·K或者k千字节（KiloByte，KB）。
    ·M或者m兆字节（MegaByte，MB）。 
    1. gzip_buffers 4 8k;
    2.  
    3. client_max_body_size 64M;
    当指定时间时，可以使用的单位包括：
    ·ms（毫秒），s（秒），m（分钟），h（小时），d（天），w（周，包含7天），
    M（月，包含30天），y（年，包含365天） 
    1. expires 10y;
    2. proxy_read_timeout 600;
    3. client_body_timeout 2m;

    注意：

    配置项后的值究竟是否可以使用这些单位，取决于解析该配置项的模块。如
    果这个模块使用了Nginx框架提供的相应解析配置项方法，那么配置项值才可以携带单位。 、

    Nginx服务的基本配置

    Nginx 在运行时，至少必须加载几个核心模块和一个事件类模块。这些模块运行时所支
    持的配置项称为基本配置 —— 所有其他模块执行时都依赖的配置项。
    下面详述基本配置项的用法。由于配置项较多，所以把它们按照用户使用时的预期功能
    分成了以下 4 类
      用于调试、定位问题的配置项。
    ·正常运行的必备配置项。
    ·优化性能的配置项。
    ·事件类配置项（有些事件类配置项归纳到优化性能类，这是因为它们虽然也属于
    events{}块，但作用是优化性能）。
  • 相关阅读:
    MySQL函数
    Numpy 计算平均值，中位数，方差，标准偏差
    基于Levy飞行的飞蛾扑火优化算法-附代码
    d的is表达式
    TinyWebServer学习笔记-Config
    四大主流BI工具的对比分析！
    jvm 类和类加载器 、双亲委派模型、自定义类加载器
    〖大前端 - ES6篇②〗- let和const
    BigDecimal应用——计算费用场景中用到Integer，Double，BigDecimal三种类型出现的意外情况 & 结合BigDecimal源码分析
    银行的商业模式分析
  • 原文地址：https://blog.csdn.net/qq_62309585/article/details/128098743