nginx在网络请求中的作用以及它是如何做的

·  阅读 794

nginx是一种高性能的HTTP和反向代理服务器。当我们要向外界发布应用的时候,如果只有1台服务器,那么直接将DNS配置解析到这台部署的服务器即可实现诉求,但是随着访问量的增大,我们需要部署多台服务器来增加服务的性能,这时就可以使用nginx作为反向代理,将流量均衡的分摊到每台服务器上。

正向代理 与 反向代理:

  • 正向代理:客户端知道要访问的地址,但是可能无法直接访问,因此客户端自己配置了一台可以访问到的代理服务器完成访问image.png
  • 反向代理:客户端不知道访问的服务器到底是代理还是应用服务器image.png

参考书籍 《nginx a practical guide to high performance》

从nginx的视角来看请求

image.png

离消费者近的称为下游,离消费者远的称为上游

事件模型

nginx是一个事件驱动架构的Web服务器,在处理网络事件时,由于网络事件取决于不同的操作系统平台,针对不同的操作系统,nginx有对应的事件驱动机制,比如linux的epoll事件驱动机制。

epoll是用来监控多个文件描述符,看它们的IO是否已经就绪。epoll和核心是epoll实例,通过3个系统调用能够对它进行创建和管理

  • epoll_create 创建epoll对象
  • epoll_ctr 对epoll实例中的实体进行增删改
  • epoll_wait 拿到已经准备好的文件描述符,如果没有会等待IO事件发生

通过事件模块提供的ngx_handle_read_eventngx_handle_write_event方法,可以把相应事件添加到epoll中,当事件发生时,事件模型会调用对应事件的handler回调方法执行具体的逻辑,对于超时逻辑处理,则可以将读事件、写事件添加到定时器中,当超时反生时,同样会调用对应事件的handler回调方法执行具体的逻辑,从而各个模块通过实现对应的handler来完成整体的逻辑

TCP连接包括一个读和写事件,HTTP本身是基于一个TCP连接实现的,也可以抽象看做和TCP一样有两个事件,这样便可以应用事件模型来处理所有的请求

nginx的部署架构

nginx采用一个master管理进程、多个完全相同的worker工作进程、一个可选的cache manager进程以及1个可选的cache loader进程 image.png

  • master不会为用户请求提供服务,它只是用来启动、停止、监控或者使用其它行为来控制worker进程
  • worker多进程部署充分利用多核CPU,提高并发处理能力

惊群问题

惊群:假设某一时刻恰好所有的worker进程都休眠且等待新连接到来,当请求到来的时候,实际上只需要1个worker来处理,其它worker是不需要被唤醒的。
为了解决这个问题,nginx规定同一时刻只能有唯一一个worker子进程监听web端口

如何限制某一时刻仅能有一个子进程监听web端口

一种方式是worker在获取进程之间的同步锁之后,才能进行监听,没有获取就不会收到新连接事件。这个机制意味着当worker持有了锁之后,需要尽快的释放锁,为了达到目的,nginx使用了两个队列:

  • posted_accept_events队列,处理accept事件,处理完之后立即释放锁
  • posted_events队列,处理read write事件

通过accept_mutex即可配置是否使用锁,在nginx 1.11.3 之前默认是开启,在这个版本以及之后,默认是关闭,只要系统支持 EPOLLEXCLUSIVE或者使用reuseport就没有必要再开启了

使用锁的方式可能还会引起负载均衡的问题某个进程过于活跃,抢到了所有的任务,其它进程就没有任务,解决方式是通过变量ngx_accept_disabled自减、自增来实现。

  • 当拿到一定的连接量的时候,通过预定好的公式ngx_accept_disabled就会大于0,不进行抢锁
  • 也为了防止大家都不进行抢锁,又给将来的自己一个抢锁的机会,ngx_accept_disabled会自减,

具体可戳我

参考

nginx惊群应对措施的改变
EPOLLEXCLUSIVE相关说明
reuseport相关说明
nginx对reuseport的支持
man epoll
书籍 < nginx a practical guide to high performance>
书籍 <深入理解Nginx 模块开发与架构解析>

分类:
后端
分类:
后端
收藏成功!
已添加到「」, 点击更改