面试中的nginx高可用高并发!

本文转自:91博客;原文地址:http://www.9191boke.com/439923471.html

面试题:

nginx高可用?nginx 是如何实现并发的?为什么nginx不使用多线程?nginx常见的优化手段有哪些?502错误可能原因有哪些?

面试官心理分析

主要是看应聘人员的对NGINX的基本原理是否熟悉,因为大多数运维人员多多少少都懂点NGINX,但是真正其明白原理的可能少之又少。明白其原理,才能做优化,否则只能照样搬样,出了问题也无从下手。

懂皮毛的人,一般会做个 Web Server,搭建一个 Web 站点;初级运维可能搞个 HTTPS 、配置一个反向代理; 中级运维定义个 upstream、写个正则判断;老鸟做个性能优化、写个ACL,还有可能改改源码(小编表示没有改源码的能力)。

面试题剖析

1. Nginx 是如何实现高并发的?

异步,非阻塞,使用了epoll 和大量的底层代码优化。

如果一个server采用一个进程负责一个request的方式,那么进程数就是并发数。正常情况下,会有很多进程一直在等待中。

而nginx采用一个master进程,多个woker进程的模式。

  • master进程主要负责收集、分发请求。每当一个请求过来时,master就拉起一个worker进程负责处理这个请求。
  • 同时master进程也负责监控woker的状态,保证高可靠性
  • woker进程一般设置为跟cpu核心数一致。nginx的woker进程在同一时间可以处理的请求数只受内存限制,可以处理多个请求。

Nginx 的异步非阻塞工作方式正把当中的等待时间利用起来了。在需要等待的时候,这些进程就空闲出来待命了,因此表现为少数几个进程就解决了大量的并发问题。

每进来一个request,会有一个worker进程去处理。但不是全程的处理,处理到什么程度呢?处理到可能发生阻塞的地方,比如向上游(后端)服务器转发request,并等待请求返回。那么,这个处理的worker很聪明,他会在发送完请求后,注册一个事件:“如果upstream返回了,告诉我一声,我再接着干”。于是他就休息去了。此时,如果再有request 进来,他就可以很快再按这种方式处理。而一旦上游服务器返回了,就会触发这个事件,worker才会来接手,这个request才会接着往下走。

2. 为什么 Nginx 不使用多线程?

Apache: 创建多个进程或线程,而每个进程或线程都会为其分配 cpu 和内存(线程要比进程小的多,所以worker支持比perfork高的并发),并发过大会耗光服务器资源。

Nginx: 采用单线程来异步非阻塞处理请求(管理员可以配置Nginx主进程的工作进程的数量)(epoll),不会为每个请求分配cpu和内存资源,节省了大量资源,同时也减少了大量的CPU的上下文切换。所以才使得Nginx支持更高的并发。

3. Nginx常见的优化配置有哪些?

(1) 调整worker_processes

指Nginx要生成的worker数量,最佳实践是每个CPU运行1个工作进程。

了解系统中的CPU核心数,输入

  1. $ grep processor / proc / cpuinfo | wc -l

(2) 最大化worker_connections

Nginx Web服务器可以同时提供服务的客户端数。与worker_processes结合使用时,获得每秒可以服务的最大客户端数

最大客户端数/秒=工作进程*工作者连接数

为了最大化Nginx的全部潜力,应将工作者连接设置为核心一次可以运行的允许的最大进程数1024。

(3) 启用Gzip压缩

压缩文件大小,减少了客户端http的传输带宽,因此提高了页面加载速度

建议的gzip配置示例如下:( 在http部分内)

(4) 为静态文件启用缓存

为静态文件启用缓存,以减少带宽并提高性能,可以添加下面的命令,限定计算机缓存网页的静态文件:

  1. location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
  2. expires 365d;
  3. }

(5) Timeouts

keepalive连接减少了打开和关闭连接所需的CPU和网络开销,获得最佳性能需要调整的变量可参考:

6) 禁用access_logs

访问日志记录,它记录每个nginx请求,因此消耗了大量CPU资源,从而降低了nginx性能。

完全禁用访问日志记录

  1. access_log off;

如果必须具有访问日志记录,则启用访问日志缓冲

  1. access_log /var/log/nginx/access.log主缓冲区= 16k

4. 502报错可能原因有哪些?

1) FastCGI进程是否已经启动

(2) FastCGI worker进程数是否不够

(3) FastCGI执行时间过长

(4) FastCGI Buffer不够

nginx和apache一样,有前端缓冲限制,可以调整缓冲参数

  1. fastcgi_buffer_size 32k;
  2. fastcgi_buffers 8 32k;

(5) Proxy Buffer不够

如果你用了Proxying,调整

  1. proxy_buffer_size 16k;
  2. proxy_buffers 4 16k;

(6) php脚本执行时间过长

将php-fpm.conf的

  1. <value name="request_terminate_timeout">0s</value>

0s改成一个时间

原文地址:https://www.cnblogs.com/007sx/p/10987200.html

时间: 2024-12-28 14:57:37

面试中的nginx高可用高并发!的相关文章

高可用高并发的 9 种技术架构!

1.分层分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统.在网站的分层架构中,常见的为3层,即应用层.服务层.数据层.应用层具体负责业务和视图的展示:服务层为应用层提供服务支持:数据库提供数据存储访问服务,如数据库.缓存.文件.搜索引擎等.分层架构是逻辑上的,在物理部署上,三层架构可以部署在同一个物理机器上,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,即三层结构分

简谈9种高性能高可用高并发的技术架构

每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心.这样,你就能一次又一次地使用该方案而不必做重复工作. 所谓网站架构模式即为了解决大型网站面临的高并发访问.海量数据.高可靠运行等一系列问题与挑战.为此,在实践中提出了许多解决方案,以实现网站高性能.高可靠性.易伸缩.可扩展.安全等各种技术架构目标. 一.分层 分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对简单并比较单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统

keepalived+LVS 实现双机热备、负载均衡、失效转移 高性能 高可用 高伸缩性 服务器集群

本章笔者亲自动手,使用LVS技术实现实现一个可以支持庞大访问量.高可用性.高伸缩性的服务器集群 在读本章之前,可能有不少读者尚未使用该技术,或者部分读者使用Nginx实现应用层的负载均衡.这里大家都可以阅读本章,即使部分读者使用Nginx负载均衡,但是在大流量下性能相对于工作在链路层的LVS真是不能同日而语,并且LVS不仅可以实现WEB方面的负载均衡,其他诸如数据库.FTP.Mail等都可以实现. 通常对于小型网站,很多都使用单台服务器,顶多在弄个缓存服务器.数据库服务器.但是一旦流量上来,单台

PHP开发高可用高安全App后端 视频教程

1-1 App项目功能介绍1-2 项目功能需求分析1-3 数据表ER关系总图对应讲解2-1 项目环境搭建及postman等工具介绍2-2 thinkphp5.0的安装2-3 项目后台模板的搭建3-1 后台用户表的设计3-2 新增后台用户功能开发3-3 后台验证码功能开发3-4 后台登录功能开发(上)3-5 后台登录功能开发(下) 3-6 后台退出登录功能开发3-7 后台权限控制功能的实现4-1 娱乐新闻表结构设计4-2 上传图片插件准备工作介绍4-3 新闻内容添加--图片上传到本地服务4-4 高

PHP开发高可用高安全App后端

let 课程地址 = " http://icourse8.com/PHP_gaobingfa.html "; 章节信息 第1章 课程介绍第2章 课前准备工作第3章 后台登录功能详解第4章 娱乐新闻内容管理第5章 restful api那些事第6章 API数据安全解决方案第7章 APP-API基础信息接口开发以及接口文档详解第8章 APP版本升级业务开发第9章 登录.个人中心.点赞以及评论功能开发第10章 APP端异常.性能监控及定位分析第11章 打造APP消息推送服务第12章 课程总结

ysql+heartbeat+DRBD+LVS实现mysql高可用

在企业应用中,mysql+heartbeat+DRBD+LVS是一套成熟的集群解决方案,通过heart+DRBD实现mysql的主 节点写操作的高可用性,而通过mysql+LVS实现数据库的主从复制和mysql的读操作的负载均衡.整个方案在读写方面进行了分离,融合了写操作的高 可用和读操作的负载均衡,是一个完美又廉价的企业应用解决方案 目前流行的高可用解决方案: mysql的复制功能是通过建立复制关系和两台和多台机器环境中,一台机器出现故障切换到另一台机器上保证一定程度的可用性 mysql的复制

jeesz分布式架构-分布式高可用

版权声明:本文为博主原创文章,未经博主允许不得转载. 什么是高可用 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间. 假设系统一直能够提供服务,我们说系统的可用性是100%. 如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%. 很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时. 如何保障系统的高可用 我们都知道,单点是系统

大型网站技术架构 读书笔记4 高可用架构

说句掏心窝的话,高可用甚至比高性能更重要.为什么? 因为你把系统的性能优化10倍,你的老板可能会说:小董呀,干的不错. 可是,如果你负责的模块,三天两头就宕掉了,嘿嘿,你懂得. 可用性度量 99%-----网站年度不可用时间小于88个小时 99.9%---网站年度不可用时间小于9个小时 99.99%---网站年度不可用时间小于53分钟 高可用架构 一般的互联网公司大多采用pc级服务器,开源的数据库和操作系统,这样来说,当然节省成本,不过另一方面来说,服务器宕机就是一个大概率事件了. 所以,高可用

高可用的作用,服务器虚拟化软件的常用功能

?高可用 高可用是资源池中的某些物理主机出现故障后,故障物理主机上的虚拟机会在资源池内其他正常的物理主机上启动,从而保障资源池安全可靠的持续运行,是服务器虚拟化软件的常见功能. 配置高可用的前提是使用共享存储部署虚拟机镜像,启用高可用后,当系统检测到主机故障时,系统将根据配置信息,将故障虚拟机在正常的计算节点上重新创建.高可用有如下配置选项,用户可根据自己的实际业务和组网,配置不同规则保证最大限度的业务连续性. 设置最大物理主机故障数 当资源池故障物理主机数量超过设置值时,故障物理主机上的虚拟机