nginx是一个性能非常强的高并发处理服务器，他可以支持百万级并发的需求
Worker抢占机制
当nginx启动时候，master在80端口监听，他的作用仅仅是监听，与客户端连接的是worker，例如现在在nginx.conf里配置worker_processes 3，那么master就会fork三个worker进程用于处理客户连接，当有一个客户端连接过来的时候，3个worker就会去抢这个客户连接，nginx采用互斥锁accept_mutex进行线程互斥，抢到锁的worker 1就会去处理这个客户连接，其余的worker继续等待。
mutex
clients
workers
master
fork
fork
fork
accept_mutex
client 1
worker 1
worker 2
worker 3
master :80
当worker 1处理完client 1的请求并返回后，client 1的这次连接才算是彻底结束，下一次再请求，workers又会重复上面的抢锁过程。
传统服务器的事件处理
传统服务器的事件处理方式一般采用BIO的方式，可以比喻成一个worker对一个client，当这个client的请求处理占用时间过长，会直接导致其他client请求排队等待worker空闲，这种情况在nginx中简单粗暴的处理方式就是增加更多的worker_processes，建立更多的workerN对clientN的方式，但是这种方式肯定是错误的，大量的worker进程会造成服务器cpu满负荷运转，成本是不可接受的。
Nginx事件处理
use epoll，linux的epoll模型，linux直接内置epoll，因此部署在linux上的nginx其单个worker进程是有能力同时处理7w左右的请求的，当然如果服务器配置够高，cpu够多内存够大，单个work进程并发数量甚至可以达到百万级别，这也就是为什么一台nginx可以做到百万、千万甚至亿级并发的原因。
因此在配置nginx的worker_processes时，一般根据cpu数量配置或者配置N-1个。
那么就需要涉及到另外一个参数：events里的worker_connections，这个参数是配置单个worker处理连接数的上限，默认值是1024。这个参数需要根据服务器硬件条件决定，如果配置过高可能导致服务器cpu满负荷运行，配置过低又会导致client连接卡顿出现阻塞现象，因此这个值实际配置需要通过压力测试来决定了。
前面提到的epoll也是配置在events里面的，nginx默认使用就是epoll，也可以不用手动配置。
总结
1、worker抢占机制
2、事件处理模型epoll的异步非阻塞性质，一种多路复用器的模式
3、master监听协调作用，当一个worker处理client被阻塞的时候，worker不会等待而是会去处理其他的连接请求
趣味概念
- 同步阻塞BIO： 我去上厕所，这个时候坑位都满了，我必须等待坑位释放了，我才能上吧？！此时我啥都不干，站在厕所里盯着，过了一会有人出来了，我就赶紧蹲上去。
- 同步非阻塞NIO： 我去上厕所，这个时候坑位都满了，没关系，哥不急，我出去抽根烟，过会回来看看有没有空位，如果有我就蹲，如果没有我出去接着抽烟或者玩会手机。
- 异步阻塞： 我去上厕所，这个时候坑位都满了，没事我等着，等有了新的空位，让他通知我就行，通知了我，我就蹲上去。
- 异步非阻塞AIO： 我去上厕所，这个时候坑位都满了，没事，我一点也不急，我去厕所外面抽根烟再玩玩手机，等有新的坑位释放了，会有人通知我的，通知我了，我就可以进去蹲了。
