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通过这种机制才能高并发的完成众多请求的处理。

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

相关文章
相关标签/搜索