1.初识nginx

​在一个遥远的乡村发生了一件事，村里的邮差老王要退休，同时宣布小张成为新一任的邮差，继续为村民服务。这里的村民生活的nginx帝国地域辽阔，人口众多。帝国和百姓沟通的媒介就是各村的邮差。村民平时遇到问题只需要交给邮差，国王就会迅速将处理 a结果交由邮差带回。

这天村民李二将一张名为”https://xxx.com/abc?name=li“ 的凭条交给了小张，在师父老王的陪同下开始了继任工作以来的第一次任务。小张了解到各村都有大量的人去帝国办理事情，将行李包里装的满满当当。正在为自己准备充分而心里暗喜时，却发现师傅老王只是轻装上阵。

小张很疑惑的问师傅：“国家人口众多，国王能处理的过来这么多请求吗？如果要等待很长的时间呢？”。老王则让小张也带些简单物品就上路了，并顺带解释了nginx的多进城的部门结构和异步非阻塞的事件处理机制。

首先，nginx国王在首都建立了一个完善的中央政府机构叫master，来接收全国各地的请求。实际上中央系统master并没有真正去处理这些事务，而是交给了自己的几个地方政府worker。master负有监管的责任，当某个worker系统故障瘫痪，或者国王需要更新服务配置时，国王就会向master发送信号，master接收到信号后，会组建一个新的继任者worker来处理新的请求，老的worker将所有未处理的请求完成后就光荣退休了。

小张问：“这么多worker，一个请求会不会被多个worker去执行，而系统在worker间不停切换导致损耗大量的资源？”老王好像早已经知道小张的疑惑，国王安排的worker之间是平等的关系，他们各自复制了和master中央系统一样的结构。一个请求进来，worker会去竞争一把锁accept_mutex，抢到锁之后就开始处理读取，解析，处理请求，产生数据结果返回出来，最终完成这次请求，都只在一个worker中处理的。对于每个worker来说，独立的空间，相互之间不会影响，其他worker发生故障也不会影响自己。

小张问：“master将请求分给worker，一个worker处理一个请求，处理速度怎么会快？并发怎么会高呢？”。这就是nginx的“异步非阻塞”了，老王解释道。我们的请求到nginx要经过多部门的一系列操作，nginx同时监控多个事件，如果某一步操作比较耗费时间，nginx就会返回AGAIN信号来告诉我们该事件还没有处理好，需要等待一些时间，nginx在这段时间就去处理其他人的具体请求了，nginx通过这种机制才能高并发的完成众多请求的处理。

这样虽然同时处理的请求就一个，但是在请求间不停地切换，只处理准备好的事件。同时高效率处理大量的请求，而没有产生过多的资源浪费。