Nginx: 配置项之events段核心参数用法梳理

本文主要是介绍Nginx: 配置项之events段核心参数用法梳理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

events 核心参数

看一下配置文件 events 段中常用的一些核心参数

经常使用的参数并不多，比较常配置的就这6个

1 ) use 含义是 nginx使用何种事件驱动模型

这个事件驱动模型和linux操作系统底层的IO事件处理模型有关系
语法：use method
method可选值：select、poll、kqueue、epoll、/dev/poll、eventport
- 这个method不同于我们HTTP的method，在这里是指操作系统底层的一个IO处理模型
- 一个事件驱动模型采用的一个参数, 比如说以前最早使用的web服务器
- 像Apache，也就是我们的 httpd 它经常最初使用的是一个select的这样一个模型
- 那包括后来有改进的其他型
- 现在新的linux系统操作系统中，一般比较长用的都是 epoll 这样的一个事件驱动模型
- 这个事件驱动模型是比较先进的，在高并发的系统中经常使用
默认配置：无
推荐配置：不指定，让nginx自己选择
- 其实在这默认配置的情况下是没有的，不推荐对这个参数做配置
- 因为在最早的Nginx版本中会需要使用 use 这样一个参数来指定
- 因为linux可以用在多个平台上, 比如说, Solus 或惠普unix这些小型服务器上
- 通常情况下，它有时候早期会有这样一种事件驱动模型: /dev/poll
- 这个eventport 也是在 Solus 操作系统上
- 我们实际使用中，也不会去指定，Nginx 会默认选择最优的驱动模型

2 ) worker connections 含义是 worker子进程能够处理的最大并发连接数

语法：worker connections number
默认配置：worker connections 1024
- 可以看到默认配置是 1024, 但是对在我们生产环境中，尤其对一个高并的系统，这个值是不足以承载的
- 比如说，你现在有一个8核心的CPU，配置成 1024 的话，每一个 work connections 处理并发连接数是 1024
- 配置8个worker子进程的话，它的处理能力最高可能也就是到一万左右
- linux自身有一个最大的打开套接字的一个个数，也就是最大的一个打开文件个数是 65535 的一个上限
- 是由我们操作系统本身所决定的，所以说，你这个work_connections 即使 20 w，也没有太大意义
- 但是在很多的生产环境中，还是能是能够看到这样的配置，比如配置成 10 w
- 最起码来说，你现在即使有一个worker子进程的话，也不会被操作系统所限
- 虽然达不到 10 w，但是也能够充分去利用操作系统来尽可能提高并发连接的一个请求数
推荐配置：worker_connections 65535/worker_processes | 65535
- 比如在 main 段中, worker_processes 是 4，那就是 65535 / 4 取整
- 直接配置成 65535 也问题不大，这是动态的配置，可在高性能的nginx服务器上配置更高的数值

3 ) accept_mutex 含义是是否打开负载均衡互斥锁

注意，3 和下面的 4, 5 配合一起使用的
语法：accept_mutex on | off
可选值：on、off
默认配置：accept_mutex off
推荐配置：accept_mutext on
下面看下具体什么是 accept_mutex

在实际的这个环境中，Nginx 的进程结构是有 master 进程，folk 出了多个worker子进程
真正处理请求的是我们的 worker 子进程，现在有一个客户端发送一个 HTTP 请求到 master 主进程
这个时候，master 进程会去找对应的一个 worker process，把这个请求分给它
这里就会涉及到一个问题，就是这个master进程是去找哪一个worker子进程呢？
找到其中一个发送，还是每个都通知一下呢，因为配置了 mutex，也就是互斥开关为 on
在默认关闭 off 的情况下，主进程会群发事件，通知到每一个子worker进程, 这就唤醒了每个子进程
在一个高并发系统里，每一个 worker 进程都在处理很多请求
现在又来了一个，肯定要处理，并且耗费性能
当设置为 on 的时候，意味着每个worker子进程中加上了一个锁 (负载均衡锁)
这个锁会轮流的将请求由 master process 分发给每一个worker

4 ) accept_mutex_delay 含义是新连接分配给worker子进程的超时时间

前置条件：上面 accept_mutex 配置成 on
语法：accept_mutex_delay time
默认配置：accept_mutex_delay 500ms
推荐配置：accept_mutext_delay 200ms
还是参考上面那个图，当一个新的HTTP请求到来以后, 告诉 master process
master process开始去找某一个work子进程来处理，根据负载均衡锁，我们找到了其中某一个
它会轮询的来分配任务，比如第一次分给A worker，第二次分给B worker，…
假如要分配给B worker, 但是它可能正在处理很多的其他并发连接，在繁忙状态，可能响应不过来
在定义了 accept_mutex_delay ，比如值为 500ms, 在这个时间内没有响应，就会分配给其他worker
避免了一直等待的问题，有时候可以为了提高性能，缩小上面的值，比如 200ms, 100ms

5 ) lock_file 含义是负载均衡互斥锁文件存放路径【main 段，辅助说明 events 段】

语法: lock_file file
默认配置: lock_file logs/nginx.lock
推荐配置: lock_file logs/nginx.lock 同默认
lock_file，其实就是我们的负载进行锁，master process 会去看一下这个锁
每一次需要分配新的请求给某一个worker子进程的时候
会把相关的信息写在这样一个锁文件中
注意，这个字段是在main段中配置的，不属于events
在这里主要是配合 events 字段做相关说明

6 ) muti_accept 含义是 worker子进程可以接收的新连接个数

语法：multi_accept on | off
可选值：on、off
默认配置：multi_accept off
推荐配置：multi_accept on
worker 子进程在某一时刻，只能处理一个连接请求
比如说一个新的用户请求到来以后，在某一时刻通常 worker 子进程只会接收一个新的
就说你一次只给我一个新的连接，接收之后，对它进行处理
打开这样一个参数之后，意味着每一个worker子进程一次性能够连接多个APP请求
这个配置对性能的影响是很小的，虽然每一个worker子进程在某一时刻只能处理一个新的连接
但是其实它已经是很高效的，所以，我们打开还是关闭对性能的影响并不大

示例配置

1 ) 主要配置

lock_file logs/nginx.log; # 这个在 main 段中events {worker connections 17500；accept_mutex on;accept_mutex_delay 100ms;multi accept on;# use epoll; # 这个一般不指定
}

2 ) 其他注意事项