初探nginx架构###
淘宝团队的nginx教材
nginx版本1.12
- nginx与外界，nginx的master与worker之间都是通过信号相连接的。
例子：从容的重启
master接受到信号后，重新加载配置，用新配置fork新的worker出来。
master向老的worker发送信号，老的worker收到信号后，不再接受处理新的连接。
老的worker处理完现有连接后，从容退出。
这样，利用信号就达到了不中断服务的重新加载配置。
相关代码：[20170512更新]
1）ngx_process.c：signals全局数组，line 39，定义了所有的信号名（nginx自定名和系统信号名的对应）
2）ngx_config.h：NGX_RECONFIGURE_SIGNAL 被定义为SIGHUP
3）ngx_process.c：ngx_signal_handler，所有的信号处理函数都被归到一个信号处理函数中，用switch处理，对于worker进程，SIGHUP被忽略了，对于主进程，它把一个全局的变量（类型sig_atomic_t，待扩展）ngx_reconfigure设置成了1。
4）ngx_process_cycle.c(os/unix)：3）提到的ngx_reconfigure被设置成1之后，主循环有一个判断，调用了ngx_start_worker_processes。重新建立了几个类型为JUST_RESPAWN的worker，这些是新worker。然后向所有进程发送NGX_SHUTDOWN_SIGNAL（定义为SIGQUIT）
5）3中ngx_signal_handler中worker部分，对NGX_SHUTDOWN_SIGNAL的处理是置全局变量ngx_quit = 1；前面提到的worker_process_cycle中对这个进行了判断，关闭监听套接字，关闭空闲连接，然后退出进程。（关于SIGCHLD的跟踪待扩展）
6）子进程退出会有SIGCHLD信号触发，ngx_signal_handler会设置ngx_reap = 1并且waitpid等到退出子进程的pid，线性遍历数组找到子进程的控制块，设置.exited = 1；主进程会去reap .exited=1的子进程。
结论：SIGHUP触发主进程的RECONFIGURE动作==>主进程建立新worker==>向所有老worker发送SIGQUIT信号==>收到>SIGQUIT的老worker扫尾退出==>主进程去收割老worker的尸体。热重启完成。
- nginx保证每个worker等概率接受处理请求的方法
nginx没有用一个线程接收然后分发到各个线程中去的做法。master进程初始化listenfd，然后fork出worker进程，worker进程持有listenfd，在注册读事件前抢一个全局的accept_mutex互斥锁，抢到互斥锁的那个进程，向epoll注册读事件，所以接受连接这件事，都是worker在做。
但是这样做肯定会有不公平的事情发生：ngx_accept_disabled变量，它定义为worker所能承受的最大连接数 * 1/8 - 空闲连接数，当空闲连接数小于最大连接数的1/8时，ngx_accept_disabled大于零，此时的worker就不会去抢锁了，转而变为每次抢锁的时候，会将ngx_accept_disabled减1，直至该变量小于0。
相关代码：
ngx_event.c：try_lock_accept_mutex()去获得锁，然后获得锁的进程去注册accept事件。
美团面试问到：如果你自己设计服务器，设计为多进程还是多线程？
答案几乎一定是多进程，就是因为进程CRASH了，其他的进程还不受影响，只影响一部分服务，线程如果CRASH了
整个进程就都没了。
