Nginx进程模型解析

• master进程: 主进程
• worker进程: 工作进程

默认是一个主进程, 一个工作进程, Nginx的工作进程是可以通过配置文件进行修改的

# 工作进程数量

worker_processes  1;

修改nginx.conf配置, 修改为2

记得每次修改完成配置文件都进行检查一下, 避免发生错误

检查完成没有问题, 就可以重启Nginx了, 修改完成Nginx必须重启, 不然配置无法生效

重启完成后,再次查看, 工作进程变成了2个

执行过程

客户端发送请求到Master, 然后通过master进行请求分发, 到不同的worker, 然后通过worker与client进行交互

Worker抢占机制

worker在与client交互的过程中, 会需要进行锁的抢占, 谁争取到了,就进行处理, 没有争取到的进入等待

传统服务器事件处理

在传统的事件服务器中, 一个工作进程只能在同一时间处理一个客户端的请求, 一旦发生阻塞, 那么就需要开启新的进程处理新的请求, 这是典型的BIO同步阻塞模型, 缺点也非常明显, 在有大量请求过来的时候, 一旦发生阻塞, 就会开启大量的线程,造成资源的浪费和CPU标高问题, 这也是BIO的典型问题

Nginx事件处理

在Nginx的事件处理中, 一个工作进程可以在同一时间处理多个客户端的请求, 一个客户端请求发生阻塞, 并不会影响到该进程处理其他的请求, 这就是为了解决BIO的问题, 所产生的NIO同步非阻塞模型, 解决了BIO模型的痛点, 那就是一个工作进程只能处理, 一个客户端请求的问题, 在Linux上采用epoll也就是多路复用技术, 很明显的提高了性能和请求的并发量

那么如何配置这个客户端的最大连接数呢

events {
    # 默认使用 use epoll
    use epoll;
    # 每个worker允许的客户端最大连接数, 默认为1024, 可以修改
    worker_connections  1024;
}

没错, 记得修改完之后重启一下nginx

标签：BIO,请求,04,worker,Nginx,进程,解析,客户端
来源： https://www.cnblogs.com/flower-dance/p/16662860.html