现在的位置: 首页 > 云计算 > 正文

nginx高可用是什么意思?nginx如何处理http请求

2020年01月06日 云计算 ⁄ 共 1895字 ⁄ 字号 评论关闭

  nginx高可用是什么意思?“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。Nginx于Keepalived可以实现高可用,实现双机热备+自动切换,这种操作在现在的集群系统中,比较的常见,还有,通过keepalived和redis实现热备份的,还有和mysql实现的,类似的案例挺多。

  Keepalived是一个免费开源的,用C编写的类似于layer3, 4 & 7交换机制软件,具备我们平时说的第3层、第4层和第7层交换机的功能。主要提供loadbalancing(负载均衡)和 high-availability(高可用)功能,负载均衡实现需要依赖Linux的虚拟服务内核模块(ipvs),而高可用是通过VRRP协议实现多台机器之间的故障转移服务。

  上图是Keepalived的功能体系结构,大致分两层:用户空间(user space)和内核空间(kernel space)。

  内核空间:主要包括IPVS(IP虚拟服务器,用于实现网络服务的负载均衡)和NETLINK(提供高级路由及其他相关的网络功能)两个部份。

  用户空间:

  WatchDog:负载监控checkers和VRRP进程的状况

  VRRP Stack:负载负载均衡器之间的失败切换FailOver,如果只用一个负载均稀器,则VRRP不是必须的。

  Checkers:负责真实服务器的健康检查healthchecking,是keepalived最主要的功能。换言之,可以没有VRRP Stack,但健康检查healthchecking是一定要有的。

  IPVS wrapper:用户发送设定的规则到内核ipvs代码

  Netlink Reflector:用来设定vrrp的vip地址等。

  Keepalived的所有功能是配置keepalived.conf文件来实现的。

  nginx处理http的请求是nginx最重要的职能,也是最复杂的一部分。可以大概说下执行流程:

  请求头读取;

  解析请求行;

  解析请求头;

  读取请求体;

  开始最重要的部分,即多阶段处理; nginx把请求处理划分成了11个阶段,也就是说当nginx读取了请求行和请求头之后,将请求封装了结构体ngx_http_request_t,然后每个阶段的handler都会根据这个ngx_http_request_t,对请求进行处理,例如重写uri,权限控制,路径查找,生成内容以及记录日志等等;

  将结果返回给客户端;

  ngx_http_process_request_line函数的主要作用即是解析请求行,同样由于涉及到网络IO操作,即使是很短的一行请求行可能也不能被一次读完,所以在之前的ngx_http_init_request函数中,ngx_http_process_request_line函数被设置为读事件的处理函数,它也只拥有一个唯一的ngx_event_t *类型参数,并且在函数的开头,同样需要判断是否是超时事件,如果是的话,则关闭这个请求和连接;否则开始正常的解析流程。先调用ngx_http_read_request_header函数读取数据。

  多阶段处理是nginx模块最重要的部分,因为第三方模块也是注册在这;

  例如有人写了一个利用nginx和memcache做页面缓存的第三方模块,也可以把memcache换成redis集群等等;

  而且nginx多阶段处理有点类似python和golang web框架的中间件,后者主要是用装饰器模式,对handler一层一层封装,而nginx是用数组(链表)形式组合多阶段handler,然后按handler链表执行即可;

  客户端发送过的统一资源定位符(url)对应服务器上某一路径上的资源,web服务器需要做的仅仅是将url映射到本地文件系统的路径,然后读取相应文件并返回给客户端。但这仅仅是最初的互联网的需求,而如今互联网出现了各种各样复杂的需求,要求web服务器能够处理诸如安全及权限控制,多媒体内容和动态网页等等问题。这些复杂的需求导致web服务器不再是一个短小的程序,而变成了一个必须经过仔细设计,模块化的系统。

  nginx良好的模块化特性体现在其对请求处理流程的多阶段划分当中,多阶段处理流程就好像一条流水线,一个nginx进程可以并发的处理处于不同阶段的多个请求。nginx允许开发者在处理流程的任意阶段注册模块,在启动阶段,nginx会把各个阶段注册的所有模块处理函数按序的组织成一条执行链。

抱歉!评论已关闭.