共计 2954 个字符，预计需要花费 8 分钟才能阅读完成。
nginx 架构
nginx 在启动之后，会有一个 master 过程和多个 worker 过程。master 过程次要用来治理 worker 过程，master 过程的作用次要在于：承受来着内部的信号（例如 reload、quit 等信号命令），向各 worker 过程发送信号，监控各个 worker 过程的运行状态。
由 worker 过程来真正解决相应的申请业务。
过程模型：
那么，worker 过程又是如何解决申请的呢？每个过程解决申请的机会是相等的，当咱们提供 80 端口的 http 服务时，一个连贯申请过去，每个过程都有可能解决这个连贯，这是因为每个 worker 都是由 master fork 过去的，并且在 fork 之前都进行了 listen 的动作，所以每个 worker 都领有 listenfd，所有的 worker 过程的 listenfd 会在新连贯到来的时候变得可读，然而为了保障只有一个过程解决该连贯，所有 worker 过程会在注册 listenfd 的读事件的时候抢夺 accept_mutex。
采纳这种形式的益处：1. 过程独立，不须要加锁，省掉了锁带来的开销。2. 绝对于多线程来讲好调试。等等
事件模型:
nginx 采纳了异步非阻塞的形式来解决申请，这是为什么呢？看看一个残缺的申请过程。首先，申请过去，要建设连贯，而后才是接收数据，再发送数据。具体到零碎底层就是读写事件，而当读写事件没有筹备好时，必然无奈操作，这个时候 cpu 会阻塞期待，阻塞调用会进入内核期待，cpu 就会给他人用了，然而对于单线程的 worker 来说就不适合了，当网络事件越来越多的时候，大家都在期待 io 实现，cpu 无人应用，这个时候 cpu 使用率就低下。所以，才会有了异步非阻塞的事件处理机制，具体到零碎调用就是像 select/poll/epoll/kqueue 这样的零碎调用。它们提供了一种机制，让你能够同时监控多个事件，调用他们是阻塞的，但能够设置超时工夫，在超时工夫之内，如果有事件筹备好了，就返回。这种机制正好解决了咱们下面的两个问题，拿 epoll 为例 (在前面的例子中，咱们多以 epoll 为例子，以代表这一类函数)，当事件没筹备好时，放到 epoll 外面，事件筹备好了，咱们就去读写，当读写返回 EAGAIN 时，咱们将它再次退出到 epoll 外面。这样，只有有事件筹备好了，咱们就去解决它，只有当所有事件都没筹备好时，才在 epoll 外面等着。这样，咱们就能够并发解决大量的并发了，当然，这里的并发申请，是指未解决完的申请，线程只有一个，所以同时能解决的申请当然只有一个了，只是在申请间进行一直地切换而已，切换也是因为异步事件未筹备好，而被动让出的。这里的切换是没有任何代价，你能够了解为循环解决多个筹备好的事件，事实上就是这样的。与多线程相比，这种事件处理形式是有很大的劣势的，不须要创立线程，每个申请占用的内存也很少，没有上下文切换，事件处理十分的轻量级。并发数再多也不会导致无谓的资源节约（上下文切换）。
更多的并发数，只是会占用更多的内存而已。我之前有对连接数进行过测试，在 24G 内存
的机器上，解决的并发申请数达到过 200 万。当初的网络服务器根本都采纳这种形式，这也
是 nginx 性能高效的次要起因
nginx 基本概念
在 nginx 中，每个过程会有一个连接数的最大下限，这个下限与系统对 fd 的限度不一
样。在操作系统中，通过 ulimit -n，咱们能够失去一个过程所可能关上的 fd 的最大数，即
nofile，因为每个 socket 连贯会占用掉一个 fd，所以这也会限度咱们过程的最大连接数，当
然也会间接影响到咱们程序所能反对的最大并发数，当 fd 用完后，再创立 socket 时，就会
失败。nginx 通过设置 worker_connectons 来设置每个过程反对的最大连接数。如果该值大于 nofile，那么理论的最大连接数是 nofile，nginx 会有正告。nginx 在实现时，是通过一个连接池来治理的，每个 worker 过程都有一个独立的连接池，连接池的大小是 worker_connections。这里的连接池外面保留的其实不是实在的连贯，它只是一个 worker_connections 大小的一个 ngx_connection_t 构造的数组。并且，nginx 会通过一个链表 free_connections 来保留所有的闲暇 ngx_connection_t，每次获取一个连贯时，就从闲暇连贯链表中获取一个，用完后，再放回闲暇连贯链表外面。
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;
if (ngx_use_accept_mutex) {if (ngx_accept_disabled > 0) {ngx_accept_disabled--;} else {if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {return;}
if (ngx_accept_mutex_held) {flags |= NGX_POST_EVENTS;} else {
if (timer == NGX_TIMER_INFINITE
|| timer > ngx_accept_mutex_delay)
{timer = ngx_accept_mutex_delay;}
}
}
}那么，咱们后面有说过一个客户端连贯过去后，多个闲暇的过程，会竞争这个连贯，很 容易看到，这种竞争会导致不偏心，如果某个过程失去 accept 的机会比拟多，它的闲暇连贯很快就用完了，如果不提前做一些管制，当 accept 到一个新的 tcp 连贯后，因为无奈失去闲暇连贯，而且无奈将此连贯转交给其它过程，最终会导致此 tcp 连贯得不到解决，就停止掉了。很显然，这是不偏心的，有的过程有空余连贯，却没有解决机会，有的过程因为没有空余连贯，却人为地抛弃连贯。那么，如何解决这个问题呢？首先，nginx 的解决得先关上 accept_mutex 选项，此时，只有取得了 accept_mutex 的过程才会去增加 accept 事件，也就是说，nginx 会管制过程是否增加 accept 事件。nginx 应用一个叫 ngx_accept_disabled 的变量来管制是否去竞争 accept_mutex 锁。在第一段代码中，计算 ngx_accept_disabled 的值，这个值是 nginx 单过程的所有连贯总数的八分之一，减去剩下的闲暇连贯数量，失去的这个 ngx_accept_disabled 有一个法则，当残余连接数小于总连接数的八分之一时，其值才大于 0，而且残余的连接数越小，这个值越大。再看第二段代码，当 ngx_accept_disabled 大于 0 时，不会去尝试获取 accept_mutex 锁，并且将 ngx_accept_disabled 减 1，于是，每次执行到此处时，都会去减 1，直到小于 0。不去获取 accept_mutex 锁，就是等于让出获取连贯的机会，很显然能够看出，当空余连贯越少时，ngx_accept_disable 越大，于是让出的机会就越多，这样其它过程获取锁的机会也就越大。不去 accept，本人的连贯就管制下来了，其它过程的连接池就会失去利用，这样，nginx 就管制了多过程间连接的均衡了。